GNU bug report logs - #73812
30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs

Previous Next

Full log

Message #29 received at 73812 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>, Andrea Corallo <acorallo <at> gnu.org>
Cc: 73812 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, emacs-erc <at> gnu.org
Subject: Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads
 ERC when starting Emacs
Date: Fri, 1 Nov 2024 19:05:16 -0700

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

> - Due to my own stupidity, the version of ERC in Emacs 30 autoloads the
>   option `erc-modules', which is the most important of ERC's options and
>   among the first that users typically customize.
>
> - Because of this change, the very presence of `erc-modules' in one's
>   `custom-file' now loads all of ERC at startup, including any library
>   housing a member module, be it built-in or third-party.
>
> - Users who no longer use ERC but still have a customization entry lying
>   around will also be affected. Likewise for users who prefer running
>   multiple Emacs instances to segregate concerns.
>
> - This issue won't be solvable by installing ERC 5.6.1 from ELPA, where
>   the problematic line will have been removed, because the autoload is
>   permanently baked into lisp/ldefs-boot.el.
>
> - The problematic change will be new in Emacs 30.1.

This does not sound ideal, indeed.

I can only add that some of our users are very concerned with Emacs's
startup time, and spend a lot of time optimizing it.  Unexpectedly
pulling in all of ERC in some cases certainly won't help them.

> "J.P." <jp <at> neverwas.me> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> All in all, I'd prefer to leave this alone in Emacs 30.  We have time
>>>> to try reverting this on master and seeing whether it's a net win or a
>>>> net loss, given the past history of the issue.  (AFAIU, if you remove
>>>> this line, some change is pertinent in the manual?)
>>
>> It's been reverted on master for ten days now with no complaints:
>>
>>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1854f275
>>
>> If that's long enough to qualify as a net win, can we proceed with a
>> backport?
>
> It's been two weeks now since I was tasked with reverting this on master
> in order to assess the damage, of which none has since been reported.
>
> Apologies if I'm out of line in pressing the issue, but I'm driven by a
> need to advocate for ERC's users, who've suffered greatly in the past
> due to my cowardliness in similar situations [1]. As such, I would very
> much appreciate a final verdict on this matter.

I assume that we are talking about cherry-picking commit 1854f2751e3f to
the emacs-30 branch.

Can removing the autoload cookie cause an issue outside of ERC, or for
non-users of ERC?  If it cannot, I don't know that I'm in a better
position than you, being the ERC maintainer, to determine what kind of
negative impact removing it might have.  If anything, it sounds like it
is more risky for non-users of ERC to leave things as is?

In summary, my view is that removing it should be low risk, and it fixes
a known bug.  It's arguably minor, but does affect startup performance.
So I think it sounds good to have the patch on emacs-30.

Let's see if Eli or Andrea has anything to add here first, though.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.