Re: bug#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC

[J.P.]

Hi,

This is update #2.

I've taken Olivier's suggestions to heart regarding up-front session
identifiers and have attempted to rework my changes around them [1].

This comes in the form of (yet) another keyword parameter to the `erc'
and `erc-tls' entry points. It's currently called :id, for lack of
imagination [2], and it can only be specified in lisp code (rather than
via M-x). When non-nil, it's stored as a symbol in a new session
variable called `erc-session-id'. This value takes precedence over
network display names and dialed/announced servers when identifying
connections and grouping buffers.

What remains are unambiguous, permanent associations completely
disinterested in other session properties, even those given as
authoritative by a remote service [3]. To opt in, a user need only avail
themselves of :id.

While the only concrete use case I've found for this so far is multiple
connections to the same network, providing full support across the board
ensures we leave a lifeline for folks with other edge cases. However,
for normal, everyday use, the interface remains unchanged, and there's
really no reason to take notice of this feature.

The general user experience has improved in terms of associations being
fortified with permanent network designations, meaning they survive
disconnection and decapitation (killing of a server buffer). Among other
things, this means reengaging someone in a reused query buffer is now
doable, assuming the other party is still around and hasn't changed
their nick [4]. Additionally, swapping out TCP endpoints (for example,
moving from proxy to direct connection) or being dealt a different
regional server by a network load balancer should no longer confuse ERC.
Buffers from previous sessions are found and reused.

I'd be happy to expand on anything above or explain any other changes in
detail [5]. If you can, please try these patches. And let me know if it
would make things easier to have the latest set present in thread as
attachments, which I'll gladly make happen [6].

Thanks,
J.P.


Notes
~~~~~

[1] About their other suggestion, which involved decoupling the means of
    connection from all protocol logic: I now feel pursuing that here,
    in this bug, strays too far off mission. It's quite an endeavor
    because it would mean touching everything everywhere, so it'll have
    to wait unless someone else wants to take up the call (in which
    case, by all means).

[2] Grepping the ERC libraries for \bid\b didn't return anything of
    note, so I figured it was free for the taking (suggestions welcome).

[3] IOW, you can sustain multiple simultaneous sessions to the same
    network using the same nick, if your network supports multiple
    client/device connections.

[4] As I've noted elsewhere, IRCv3 account tags and related features
    should improve the situation here.

[5] I've also attempted to unify the auth-source interface a bit. In
    doing so, I felt the need to include one of Olivier's patches,

    bug#46777: 28.0.50; ERC: NickServ identification: Prompt for
    password after other sources, overall simplifications:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46777

[6] My prior misgivings on that front were based on not wanting to
    further clutter people's inboxes and overburden gmane. However,
    these fears were probably misplaced. I've since found change sets of
    similar size (still under 1 MiB) that didn't seem to elicit much in
    the way of complaints.