bug#59976: ERC 5.4.1: erc-networks--id gets clobbered in erc server buffer on /query name conflict

["J.P." <jp@neverwas.me>]

Mike Kazantsev <mk.fraggod@gmail.com> writes:

> On Thu, 15 Dec 2022 06:16:08 -0800
> "J.P." <jp@neverwas.me> wrote:
>
>> Anyhow, I have attempted to address this in the attached patch. If you
>> or anyone out there is willing, please install it locally atop the
>> current lisp/erc subtree on the emacs-29 branch and see if you can break
>> it. Thanks in advance!
>
> I think you indeed found the same thing I was thinking of and fixed it, thanks.
>
> You mentioned connection process and how ID is being set in the previous
> message, which indeed didn't seem to be same issues as I've tried to describe
> (not clearly enough).

Well, I've long been in the terrible habit of just saying "connection"
when I really mean "logical IRC connection" and not the actual network
process. But sometimes I mean both or one then the other, which is
obviously insane but likely what happened here (so please just take
whatever I said with a grain of salt).

> So thought to make a quick mockup of an IRC server and then send it,
> with precise commands to run from ERC to reproduce exact problem,
> as well actual output from that variable-change-tracking (which shows
> how/when ID gets erased after successful connection, and only after
> triggering conflicting query-buffer creation).
>
> Haven't gotten around to do it yet though, but pretty sure you found
> and fixed same exact issue in 0001-Fix-some-naming-issues-*.patch here,
> so there should no longer be any need to do it.
>
> I've just tested removing my custom ID-setting advices/code, using :id
> instead, as well as reproducing that exact query-buffer-name conflict,
> and it all works without any issues that I can see.
> So will use that instead of local code hacks and won't need to worry
> about making server-buffer names unique/distinct.

Nice!

> One small thing I've noticed about :id is that it has separate "Network
> Identifier" section in "Connecting" info page, which doesn't seem to be linked
> directly in its description - not sure if intentional, or maybe an oversight:
>
>   When present, ID should be an opaque object for identifying the
>   connection unequivocally.  (In most cases, this would be a string or a
>   symbol composed of letters from the Latin alphabet.)  This option is
>   generally unneeded, however.  See info node ‘(erc) Connecting’ for use
>   cases.  Not available interactively.

Good catch.

> Come to think of it, I'd probably also add the most obvious effect of :id
> for naming the server buffer, i.e. something like this:
>
>   When present, ID should be an opaque object for identifying the connection
>   unequivocally, and will correspond to name of the created erc server buffer
>   after connection. ...
>
> Can probably be phrased better, but since main effect of "(erc ...)" command is
> creating that server buffer, what it will be named seem to be an important detail
> (if only for finding it afterwards).
>
> [...]
>
> In fact, I think allowing for naming server buffers how you want them
> to be named with one easy and reasonably-obvious option should probably
> be most prominent thing about it:
>
>   https://e.var.nz/scr-20221215233955.jpg
>
> (example of using :id for all networks, in contrast to earlier
> inconsistent not-entirely-local naming)

Agreed. Thanks. I have attempted to change it to something along the
lines of what you've suggested. Hopefully it's passable.

> Pretty sure patches you've attached address main issue I wanted to raise
> (as well as couple other issues).
>
> Thanks again for doing all the work here.

My pleasure. I've added the changes to Emacs 29, so they should appear
on HEAD as well, shortly.

> And apologies for not being able to articulate main problem more clearly.
> Given how simple IRC is, should've definitely attached some easy-to-run
> protocol example to reproduce it in the first place (maybe as .eld test-case),
> instead of meandering description.

Nah. Your input has made all the difference. Bug reports, especially
good ones like this, are terribly undervalued as contributions, IMO.
Please consider contributing to ERC (in any form) again in the future.

Until next time!