Re: Semantics of autoload cookies on defcustoms

[Richard Stallman]

    > In order to process the specified value, custom needs the defcustom
    > info.

    That's sometimes the case, but I can't see why it would be the case for
    diary-file.  E.g. I understand the need for custom-autoload if the defcustom
    has a :setter but for a plain defcustom such as diary-file it doesn't seem
    to make much sense.

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

    So if I understand correctly, you're saying that diary-file should simply
    not have an autoload cookie?

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.

Anyway, I proposed another approach:

    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?

Any ideas?