Re: Semantics of autoload cookies on defcustoms

[Stefan Monnier]

>> 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.

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.

>     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.

What good reason could there be?
[ The same question applies to most other autoloaded defcustoms and
  defvars, I guess. ]

> 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?

AFAICT the answer depends on what is the intention behaind
the ;;;###autoload cookie used for those vars that don't need to preload the
package (and that don't have :setters either).


        Stefan