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

[Michael Albinus]

"J.P." <jp@neverwas.me> writes:

> Hi Michael,

Hi,

I'm now at erc 5.4.1.48598.0.20220425.270. Btw, it is a little bit
tricky to decide which is the recent version, because you have two lines
of patches: erc5.4.1.48598.* and erc 5.4.1.49860.*. The package manager
always offers me to upgrade to the most recent 5.4.1.49860.* version,
and I must pick then the most recent 5.4.1.48598.* version (hoping it is
the proper decision). It might be more obvious to me if you could offer
both erc-48598 and erc-49860 packages in parallel.

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

Indeed, test/Makefile fires an error then. I've pushed a fix to master,
it shall work now with the file name erc-d-tests.el.

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

Yes. Test data and test Elisp files belong to the test/ directory.

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

Where is this needed? I don't see any load of erc-scenarios-meta.el.

And even if you need it somewhere, I believe it belongs into the
resources/ subdirectory.

> 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

Looks OK to me except the location of erc-scenarios-meta.el.

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

Well, there seems to be a cut'n'waste error in erc-services-tests.el. See
this fix:

*** 
/home/albinus/.emacs.d/elpa/erc-5.4.1.48598.0.20220425.270/test/erc-services-tests.el.~1~
   2022-04-26 08:38:20.106415131 +0200
--- 
/home/albinus/.emacs.d/elpa/erc-5.4.1.48598.0.20220425.270/test/erc-services-tests.el
       2022-04-27 14:25:08.822978791 +0200
***************
*** 465,471 ****
                ((symbol-function 'auth-source-pass-entries)
                 (lambda () (mapcar #'car store))))

!       (erc-services-tests--auth-source-announced
         #'erc--auth-source-search))))

  (ert-deftest erc--auth-source-search--pass-announced ()
--- 465,471 ----
                ((symbol-function 'auth-source-pass-entries)
                 (lambda () (mapcar #'car store))))

!       (erc-services-tests--auth-source-standard
         #'erc--auth-source-search))))

  (ert-deftest erc--auth-source-search--pass-announced ()

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

No need to sorry! That's what reviews are good for :-)

> J.P.

Best regards, Michael.