Re: Semantics of autoload cookies on defcustoms

[T. V. Raman]

The other negative consequence of putting an autoload cookie on a
defcustom is the following:

So let's say you have package foo.el and with option foo.
Let's further assume you've customized foo and saved your
setting.

If package  foo gets autloaded sometime after startup --- the
option foo ends up with its default value -- not your saved value
--- and you end up needing to do a "reset to saved".

>>>>> "Richard" == Richard Stallman <address@hidden> writes:
    Richard>     What is the intended effect of adding an
    Richard> autoload cookie on a defcustom?  It puts a defvar
    Richard> and the custom-autoload call into loaddefs.
    Richard> 
    Richard>     I ask this question because I recently noticed
    Richard> that setting variables such as diary-file via custom
    Richard> causes calendar.el to be loaded at startup, even tho
    Richard> I can't see any reason why such a setting would
    Richard> justify eagerly loading calendar.el.
    Richard> 
    Richard> There was a reason for this, and I used to know it,
    Richard> but I have forgotten.
    Richard> 
    Richard> In order to process the specified value, custom
    Richard> needs the defcustom info.  So there are two options:
    Richard> 
    Richard> 1. Save the value away and process it if/when the
    Richard> defcustom is loaded.  2. Load the defcustom now, and
    Richard> process the value right away.
    Richard> 
    Richard> #1 is the usual method.  That is fine for variables
    Richard> that aren't really defined at all until the package
    Richard> is loaded.
    Richard> 
    Richard> But when a variable is autoloaded, that means its
    Richard> value is meaningful already, and it could be used at
    Richard> any time.  So there is no correct alternative except
    Richard> #2.
    Richard> 
    Richard> Putting the actual defcustom into loaddefs would
    Richard> also work.  We would not want to do that for all
    Richard> autoloaded defcustoms.  For one thing, there are
    Richard> defcustoms for which this won't work.  For others,
    Richard> it would just waste space inside the dumped Emacs.
    Richard> But there could be some (perhaps diary-file is one)
    Richard> for which this would be better.
    Richard> 
    Richard> It would not be hard to implement this option.  How
    Richard> could we specify whether to do #2 or this?
    Richard> 
    Richard> 
    Richard> _______________________________________________
    Richard> Emacs-devel mailing list address@hidden
    Richard> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  address@hidden
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: address@hidden
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs