Re: bug#73812: 30.0.91; ERC 5.6.0.30.1: Customizing erc-modules loads ERC when starting Emacs
"J.P." <[email protected]> Sat, 16 Nov 2024 10:05:12 -0800
| Newsgroups | gmane.emacs.erc.general |
|---|---|
| Message-ID | <[email protected]> |
Some additional notes for future people investigating similar problems. To recap, when trying to autoload the option `erc-modules' for the purpose of getting M-x customize-option RET to work OOTB (a common request), I found that ;;;###autoload (defcustom erc-modules ...) meant we needed to migrate symbols used in the option's complicated :set function to the main library or else suffer an error during loaddefs generation. In ERC's case, such a migration would have defied the purpose of keeping a common base library in erc-common.el. I also noticed that adding the cookie placed the entire, massive `defcustom' definition in lisp/loaddefs.el, which seemed rather unsightly. And it also worried me, perhaps irrationally so, that such an inclusion might one day potentially interfere with newer versions installed from ELPA, though this is likely dubious. So I instead opted for a manual ;;;###autoload(custom-autoload 'erc-modules "erc") which "worked" but caused ERC to load on startup for anyone with a (custom-set-variables '(erc-modules ())) in their `custom-file'. As mentioned in this ticket's main thread, one possible interpretation is that I merely forgot to include a non-nil `noset' argument to `custom-autoload', which does indeed produce the desired behavior: ERC only loads when a user actually customizes the option. (This has been observed both on master as well as on upgrades installed atop 27+.) Unfortunately (for ERC), it seems `loaddefs-generate--make-autoload' omits `noset' for options that have a `:set' function, which may seem rather obvious. Despite this, it's still unclear to me whether our use case aligns fully with those semantics, at least as laid out in the initial discussions that led to the parameter's introduction [1] (as well as various mentions that have followed over the years [2]). Rather than press the issue, I figured we might as well abide by the guidelines set forth in the info node `(elisp) When to Autoload' =E2=80=A2 Don't autoload a user option just so that a user can set it. which makes it sound like autoloading options for our use case is basically deprecated nowadays. Anyway, if new users continue to complain, we could perhaps add a new autoloaded entry-point command, something like a `erc-customize-modules', that would basically do (require 'erc) (customize-option 'erc-modules) However, the current workaround of recommending C-h v erc-modules RET doesn't seem too strenuous a detour IMO. [1] https://lists.gnu.org/archive/html/emacs-devel/2006-07/msg00270.html [2] https://lists.gnu.org/archive/html/emacs-devel/2009-01/msg00128.html