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

[J.P.]

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'

  • 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