Christopher Howard <christopher@librehacker.com> writes:

> Hi, as mentioned earlier, I'm happy to report that the elpher SOCKS wrapper is
> working great. However, there is one little hangup for me. Personally, I like
> to have elpher-gemini-TLS-cert-checks set to ON — as it doesn't bother me to
> have to explicitly accept a new cert, as opposed to the alternative of not
> checking certs at all. However, it seems that enabling elpher-socks-always
> somehow causes cert checking to be once again disabled. Do you know if this is
> an issue in the elpher code, or something happening back in socks.el?

The problem is on the Emacs side. As things stand, you can't have `nsm'
checks without also leaking DNS. See [1] (in particular, the first two
patches), and reply to that bug thread if you'd like to see any action
on this front. Thanks.

Hi Christopher,

Christopher Howard <christopher@librehacker.com> writes:

> Hi, I want to switch over to elpher as my primary gemini client, but I have a
> requirement that I need to be able to route the connections through my TOR
> daemon, available at 127.0.0.1:9050. I see that elpher has SOCKS5 support but
> it doesn't seem to be working for me. Or perhaps I am not setting it up
> correctly.
>
> I didn't see a guide for this, but I set these variables (through Custom):
>
>  '(elpher-socks-always t)
>  '(socks-server '("Default server" "socks" 9050 5))

This adds an -events option to log JOINs, PARTs, etc., as mentioned in [1].
The log formatting in WriteMessage is copied from formatMessage in
soju/msgstore/znclog. It differs only in ZNC 1.9-style "Joins:" lines for
logged-in users [2]. "Joins:" parsing in UnmarshalLine should not be affected.

[1] https://todo.sr.ht/~emersion/chathistorysync/1
[2] https://github.com/znc/znc/pull/1870
---
 client.go   | 14 ++++++++++++
 main.go     |  4 ++++
 msgstore.go | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/client.go b/client.go
[message trimmed]

Hi, these changes appear to work for my purposes, but I'm only just trying them
out now. Perhaps others needing this functionality would like to as well. Thanks.

Hi Troels,

Troels Henriksen <athas@sigkill.dk> writes:

> Sometimes I click on a gopher:// link to a binary file in ERC (the Emacs
> IRC client), which will then invoke elpher to download it.  However,
> it'll eventually fail in `elpher-render-download` because
> `(elpher-page-address elpher-current-page)` returns NIL, and this is not
> a valid value for `elpher-address-gopher-p`.  I think the problem is
> that whatever mechanism invokes elpher through ERC (which I didn't
> manage to trace) doesn't actually switch to an elpher buffer.  Any ideas
> on how to fix it?

By default, ERC relies on `browse-url-button-open-url' for visiting most

Corwin Brust <corwin@bru.st> writes:

> A quick top-posted follow-up just to say:
>
> With your help in #erc I was able to do as you suggested.  I have a
> feeling there was reason I wanted to put the type directly into it's
> own text property but I really can't think of any now, months after
> the fact.

I think you mentioned this update in the channel a few months back, but
I responded unseasonably late or otherwise inopportunely:

  [Sun Nov  7 2021]
  <neverwas> corwin, nice! (not just saying on account of commit-msg

Please note that my understanding of anything regarding configuration
specifics is likely incomplete (see post titled "Larger config
discussion").

Also, in light of your recent work and your repo announcement to the ERC
list, the following may be obsolete. Even so, I feel I may have missed
something from earlier discussions about your reasons for adding
prefixes in the first place.

Re this issue, you stated (off list, hopefully not in confidence):
> The one detail point I want to mention right away is about the sJOIN
> vs JOIN. Considering my hack into erc-message (ignoring for a moment
> your point about the potential to use a hook for this also), uses a
> very simple "s%s" format. Do you think it's worth making that more

As I've mentioned in another post, I don't think I'm qualified quite yet
to comment on config-related matters, which is what erc-hl--flatten is
mostly about. As an aside, re the new names: I like that they're all
the same length (not a joke).

Instead, I thought I'd bother you (or anyone bored enough to humor me)
with a basic elisp question. Feel free to abstain if it's too
amateurish. I'm basically an impostor with little understanding of
internals who just copies others blindly hoping no one notices, (in case
that wasn't already clear).

  (seq-uniq        ;; specal case: we have a flat list w/o keywords
   (remove :IGNORE ;; combine and deduplate
           (append (or (and defaults (seq-copy defaults)) (list :IGNORE))

Mr. C.,

HNY (forgot to say that in the last one)! It seems you weren't a fan of
moving your changes from erc-display-message to erc-hl--insert-post-hook
as I was pushing for. If true, care to share the reason? (Don't hold
back on account of embarrassing me, if that's where this leads.)

Or, in case my earlier suggestion didn't register, I was trying to say:

1. drop the patch

2. include that functionality by gleaning the parsed response from the
   corresponding stashed text property somewhere early in your hook
   body.

At this point, your entire module rests on the one config item. And I
*do* have questions about that item's shape and interpretation. But its
design seems heavily influenced by this "sticky" configuration notion
you've emphasized. I kind of tried to stress this point in my last note,
but perhaps I wasn't clear enough.

From your initial post to the ERC list a few weeks ago:
> My hope in proposing this last point is to provide within ERC,
> something of a living experiment toward a more general solution
> declarative "grammars" that, perhaps somewhat automatically, provides
> a "fuller", "stickier" customize and or coding experience. . . .
> Granting, things could potentially get hairy fast, I think ERC might
> make a util and fertile ground to play around with this stuff.