emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Eliminating "changed in Emacs outside of Customize"


From: Luc Teirlinck
Subject: Re: Eliminating "changed in Emacs outside of Customize"
Date: Tue, 1 Feb 2005 19:03:30 -0600 (CST)

Lennart Borgman wrote:

   Could you please take this a little bit more precise? I vaugely remember the
   discussion, but not the details. It looks to me that there is a mixing of
   things. Why should :initialize execute :set if it only is for the purpose of
   initializing something, but not actually setting the symbol value? Should
   not that code then be in :initialize?

If I remember correctly, it is for the sake of autoloaded defcustoms.
For those, loaddefs.el sets the value, but does not execute the :set
function, because it does not know the :set function.  When the file
is later loaded, `custom-initialize-reset' assures that the :set
function gets executed.  This usually leads to the correct behavior
for people who customized the value using Custom, but can easily lead
to very wrong results for people who set it outside Custom.

So how do you get around the above problem if you can not use the
default :initialize function, because you do not want to force people
to use Custom to set your variable?

The problem that `custom-initialize-reset' tries to address only
occurs when the _"standard"_ (or "Stock" or ...) value requires a :set
function to be properly initialized.  I personally try to avoid such a
situation in the defcustoms I write.

The problem also does not occur if you do not autoload the defcustom.
That will become more difficult.  Indeed, `custom-set-variables' used
to (actually still does, I believe) keep track of :require's using
stuff like:

'(global-font-lock-mode t nil (font-core))

where (font-core) says to load the file "font-core".

If I understood correctly, this feature is scheduled for elimination,
because it creates incompatibility between different Emacs versions.
Instead, it is planned to autoload the defcustoms in question to
record the :require's that way.  The person implementing this will
have to very carefully grep for :initialize in addition to :require
keywords to make sure that this does not break anything.  Of course,
one could eliminate the :initialize problem completely by making
loaddefs _execute_ the :require (maybe it already does), but, unless I
misunderstand something, in that case one could just as well preload
the file and then there is no need for an autoload and there is no
problem whatsoever.

Sincerely,

Luc.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]