Re: Semantics of autoload cookies on defcustoms

[Richard Stallman <rms@gnu.org>]

    > That may be true, but Custom has to load the defcustom in order to see
    > what it does or does not have.

    But autoload does know whether there is a :setter, so it can decide whether
    to put a custom-autoload, thus informing Custom opf whether or not the
    package needs to be eagerly loaded.

That is true.  In the absence of a :set function and (perhaps) certain
other specific options, there is no need to load the file in order
to set the variable.

But it IS necessary to set the variable immediately, and not wait till
the file that defines it is loaded, in case the variable is used
elsewhere.  (This is not in fact the case for diary-file, but it could
be the case for other autoloaded defcustoms.)  This is what I proposed
as behavior #3.

Perhaps a good way to implement that is to write another argument into
the custom-autoload call.  That optional argument, if non-nil, would
specify this new combination of behaviors that I called #3.
The decision could be based on the presence of :set.

    > No, what I said does not go that far.  If it did not have an autoload
    > cookie, that would be better in this one way.  But there may be some
    > good reasons for it to have an autoload cookie.  I don't know.

    What good reason could there be?

1. To cause the variable to be visible for help commands
even if the file has not been loaded.

2. If other files use the variable.