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

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

Michael Albinus <michael.albinus@gmx.de> writes:

> Indeed, that works, thanks. I've installed erc-5.4.1.48598.0.20220420.474,
> which seems to be the most recent version. Unfortunately, it isn't
> obvious what has changed wrt vanilla erc, so I must use ediff-directories.
>
> [...]
>
> Well, this is also good. But for analysis it might be better to read the
> files with the patches applied.

Thanks for being brave and taking a look. And you're right, of course:
for sharing purposes, I really ought to keep a full copy of the entire
emacs.git somewhere, with up-to-date branches for all my open bugs.

>> What I meant to
>> say was that from my reading of that doc string (basically the de facto
>> compliance spec), a *back end* ignoring :max is fair game. But I think
>> the way I wrote it gave the misleading impression I was saying fair game
>> from the querying client's perspective. But regardless, the tramp
>> examples are indeed helpful. So, thanks for those.
>
> I wouldn't call it fair game. With the Tramp examples you have seen,
> that a :max property greater than 1 makes sense.

True that. And (I believe) it likewise makes sense for ERC's needs.

> Btw, there are further dficiencies. For example, I believe the pass
> backend does not support the :create and :remove properties (last time
> I've checked, it were only netrc and secret backends which do). But this
> is perhaps not the most important problem.

Hm... I hadn't thought to check but will keep those on my radar.

> Could you provide the (changed) test files together with the erc
> package? This makes it more simple to puzzle all changes together,
> instead of accessing different web locations.

I've added the tests to the (fake) ELPA package you installed earlier.

Appreciate the counsel, as always.

J.P.