Re: Semantics of autoload cookies on defcustoms

[Stefan Monnier]

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

Please use another thread because I don't think it's related other
than circumstantially.  And please give a precise test case.


        Stefan


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


> _______________________________________________
> Emacs-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-devel