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

"J.P." <[email protected]> writes:

> Hi Michael,

Hi,

>> You have said somewhere there is an archive at
>> <https://jpneverwas.gitlab.io/erc-tools/archive/>. I cannot access
>> this URL. Is there another URL to be used?
>
> Sorry for the confusion. That's a package.el-only endpoint without any
> browsable HTML, i.e.,
>
>   (push '("erc-tools" . "https://jpneverwas.gitlab.io/erc-tools/archive/")
>         package-archives)

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.

> For future reference, the full patch set is available for browsing here:
>
>   https://git.neverwas.me/repos/erc-tools/tree/bugs/48598/patches/wip
>
> And is downloadable here:
>
>   https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz

Well, this is also good. But for analysis it might be better to read the
files with the patches applied.

>> Indeed. In Tramp there are two calls of auth-source-search: One call in
>> order to retrieve the password, and there I use ':max 1' explicitly (see
>> `tramp-read-passwd'). And there is another function used for user/host
>> name completion, not looking for the password, and there I use ':max
>> most-positive-fixnum' (see `tramp-parse-auth-sources'). But the former
>> case could refrain from specifying :max.
>
> Wow, so my lack of communications skills strikes again!

Oh no, please don't underestimate my lack of English!

> 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.

>> Making auth-source-pass conform to the auth-source API would always be a
>> good thing™. I don't know whether there exist already such a bug report,
>> otherwise I recommend you to write a new report.
>
> Agreed. Unless Ted or Damien have anything to add, I'm going to remove
> support for pass from this patch series (at least for now, even though
> my terrible hacks seem to make it gel well enough). I'll later open a
> new bug report asking for clarification on the interface and possibly
> include a patch for making auth-source-pass :max aware.

Yes, please do so. Hacking around bugs will always result in further
trouble mid-term. A bug must be fixed where it happens.

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.

> Anyway, here is
> the relevant file (in case you're curious), which I believe reflects the
> approach you describe:
>
>   https://git.neverwas.me/repos/erc-v3/tree/test/erc-services-tests.el?id=00ad7115#n468

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.

> J.P.

Best regards, Michael.