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

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

Hi Michael,

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

> Starting slowly, just some first comments. It would be great to
> distinguish in your package the same way as between the lisp/erc/ and
> test/lisp/erc directories in the Emacs git repo. In your package, you
> might use a test/ subdirectory, which contains evrything located in
> test/lisp/erc of the Emacs git repo.

I spotted this just before receiving your email and was panicking to fix
it but was obviously way too late. It was all indeed meant to live under
a top-level test/ subdirectory, but I messed up the ELPA recipe royally,
which resulted in the terrible crime scene at hand. Apologies for the
sloppiness.

> I'm not sure about the erc-d/ subdirectory. Is it something which is
> also in the lisp/erc Emacs directory, or is it only in test/lisp/erc/?
> In the latter case, I believe the directory shall contain just a file
> test/lisp/erc/erc-d/erc-d-tests.el (currently called erc-d-self.el), and
> *all* other files shall be located at test/lisp/erc/erc-d/erc-d-resources/.

Even without the aforementioned packaging snafu, the erc-d/ situation is
definitely confusing. That subdir is supposed to house the fake IRC
server that all the "erc-scenarios"-based tests depend on. I initially
tried going with erc-d-tests.el instead of erc-d-self.el for the
server's own tests but hit a Make error because a corresponding library
didn't exist under lisp/erc/. Perhaps I should have tinkered further.

And while moving erc-d/ (minus the tests) under lisp/erc/ would make
things easier in terms of the layout, I'd rather not add more bulk to
Emacs proper without good reason, even though adding it wouldn't really
cause any problems (assuming the symbols are renamed using the internal
"--" convention).

For now, I've moved it to test/lisp/erc/erc-scenarios/resources/erc-d/
and am artificially piggybacking on check-lisp-erc-erc-scenarios via
test/lisp/erc/erc-scenarios/erc-scenarios-meta.el, which does nothing
but load erc-d-self.el (as convoluted as that sounds).

> Loading the related resource files, you use a pattern like
>
> (eval-and-compile (let ((dir (getenv "EMACS_TEST_DIRECTORY")))
>                     (when dir
>                       (load (concat dir "/lisp/erc/erc-d/erc-d") nil t)
>                       (load (concat dir "/lisp/erc/erc-d/erc-d-t") nil t))))
>
>
> That looks too complicate. There are the functions ert-resource-directory
> and ert-resource-file. You could use something like (untested)
>
> (eval-and-compile (let ((load-path (cons (ert-resource-directory) load-path)))
>                       (load "erc-d" nil t)
>                       (load "erc-d-t" nil t)))

That environment variable stuff has been driving me bananas! Yours is
much nicer (thanks) and has magically nudged me toward adopting what's
hopefully a less offensive layout, which currently looks like this:

  test/lisp/erc/
  ├── erc-tests.el
  ...
  └── erc-scenarios/
      ├── erc-scenarios-<foo>.el
      ├── erc-scenarios-meta.el
      ...
      └── resources/
          ├── <foo>/...
          ...
          ├── erc-d/
          │   ├── erc-d.el
          │   ...
          │   ├── erc-d-self.el
          │   └── erc-d-self-resources/...
          └── erc-scenarios-common.el

> In erc-services-tests.el, I would call the tests
> erc--auth-source-search--{standard,announced,overrides}
> erc--auth-source-search--netrc-{standard,announced,overrides}, because
> they are about this backend. The body of these functions is almost the
> same for the different backends; perhaps you can factor it out.

Done, thanks. (My ego says I'd have realized this eventually, but that's
probably a lie!)

> I would mark the tests erc--auth-source-search--pass-* with
> ":tags '(:unstable)" until the problems in auth-source-pass are solved.

Oh, I was going to remove those tests completely because they depend on
hacks from lisp/erc/erc-compat.el that I've since deleted. IOW, they're
guaranteed to fail (and so have been disabled). But I left them hanging
around for now in case you had something else in mind.

> Again, all of this is just cursory reading, I haven't started yet to
> read the real code.

Oh, wow! I'm quite floored by the "yet" part (though no expectations, of
course). If you do happen to take a deeper look, please take your time,
and don't sweat the IRC protocol stuff if it gets too annoying. Unlike,
say, dbus, much of IRC is dizzyingly nonsensical and is no longer bound
by any relevant specification (although work is underway in this area).

Sorry again for the packaging snafu. Despite all appearances, I really
do value your time, so please don't let this interfere (too much) with
whatever else is on your plate. You've already helped me so much, and I
owe you a ton!

J.P.