all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "J.P." <jp@neverwas.me>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 73812@debbugs.gnu.org, emacs-erc@gnu.org
Subject: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs
Date: Thu, 17 Oct 2024 12:38:05 -0700	[thread overview]
Message-ID: <87zfn28qqq.fsf__8626.00156558386$1729193950$gmane$org@neverwas.me> (raw)
In-Reply-To: <87h69ddz5l.fsf@neverwas.me> (J. P.'s message of "Tue, 15 Oct 2024 11:00:38 -0700")

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

>>> Eli, can we add this patch to the release branch? It removes a single
>>> line containing an autoload cookie that's new in Emacs 30. (I'm running
>>> the check-expensive suite with the patch now.) Thanks.
>>
>> Are we sure this doesn't break any customization scenarios?
>
> The worst case is probably someone unaware of the implicit loading who
> recently added code referring to symbols defined in erc.el after an
> Emacs-managed `custom-set-variables' form in their `custom-file' (or a
> `:custom' section in a `use-package' declaration). These customizations
> would necessarily have to contain an entry for `erc-modules', but this
> is perhaps the most common ERC customization. However, the user would
> have to be running the pre-release or master.
>
>>  Why was this line added in the first place?
>
> The line was initially added in a misguided attempt to allow new users
> unfamiliar with Emacs to run M-x customize-option RET erc-modules RET
> without first having to run M-: (require 'erc) RET.
>
>>  And why is it urgent to remove it before Emacs 30 is released?
>
> ERC has a great many symbols, which people won't want to see in
> completion tables, etc. Longtime ERC users trying Emacs 30 for the first
> time may find ERC loading whenever they start Emacs, which may not be
> desirable in all Emacs sessions. And since, as mentioned, `erc-modules'
> is likely among the most commonly customized of ERC's options, this may
> also affect non-ERC users who perhaps only tried it once many years ago
> or even folks using a shared config containing such a customization. For
> these reasons, I suspect we'll start noticing ERC-related pollution in
> the automated evidence collection for bug reports filed with M-x
> report-emacs-bug RET once Emacs 30 goes mainstream.

While we await a ruling on this...

Here's an example of how `erc-modules' customizations inadvertently
creep into a person's `custom-file' (for any curious future victims of
this bug).

From emacs -Q (using Emacs 27 as an example):

0. Connect to a server
1. M-x customize-group RET erc RET
2. Twirl open the "Erc Modules" section
3. In an ERC buffer: M-x erc-scrolltobottom-mode RET
4. In the Custom buffer, edit an option, like "Erc Email Userid"
5. C-x C-s
6. Notice that your `custom-file' now contains an entry for `erc-modules'

Among those who've ever done the above or similar, only the lucky few to
have since cleaned up their `custom-file' will be spared ERC invasively
loading when next they fire up Emacs 30.

As may be obvious, ERC is guilty of the familiar anti-pattern of
mutating user options silently behind the scenes. For reasons of
compatibility, we've put off addressing this until a major release.
FWIW, new modules following the recommended practice of declaring
themselves `local' do not exhibit this malignant behavior.





  parent reply	other threads:[~2024-10-17 19:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-15  2:57 bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs J.P.
2024-10-15 12:07 ` Eli Zaretskii
     [not found] ` <865xptsh6f.fsf@gnu.org>
2024-10-15 18:00   ` J.P.
     [not found]   ` <87h69ddz5l.fsf@neverwas.me>
2024-10-17 19:38     ` J.P. [this message]
2024-10-18  7:14     ` Eli Zaretskii
     [not found]     ` <86bjzhopaz.fsf@gnu.org>
2024-10-18 17:55       ` J.P.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='87zfn28qqq.fsf__8626.00156558386$1729193950$gmane$org@neverwas.me' \
    --to=jp@neverwas.me \
    --cc=73812@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=emacs-erc@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.