Re: Semantics of autoload cookies on defcustoms

[Richard Stallman <rms@gnu.org>]

    What is the intended effect of adding an autoload cookie on a defcustom?

It puts a defvar and the custom-autoload call into loaddefs.

    I ask this question because I recently noticed that setting variables such
    as diary-file via custom causes calendar.el to be loaded at startup, even
    tho I can't see any reason why such a setting would justify eagerly loading
    calendar.el.

There was a reason for this, and I used to know it, but I have
forgotten.

In order to process the specified value, custom needs the defcustom
info.  So there are two options:

1. Save the value away and process it if/when the defcustom is loaded.
2. Load the defcustom now, and process the value right away.

#1 is the usual method.  That is fine for variables that aren't really
defined at all until the package is loaded.

But when a variable is autoloaded, that means its value is meaningful
already, and it could be used at any time.  So there is no correct
alternative except #2.

Putting the actual defcustom into loaddefs would also work.  We would
not want to do that for all autoloaded defcustoms.  For one thing,
there are defcustoms for which this won't work.  For others, it would
just waste space inside the dumped Emacs.  But there could be some
(perhaps diary-file is one) for which this would be better.

It would not be hard to implement this option.  How could we
specify whether to do #2 or this?