standard-value of display-battery/time-mode

standard-value of display-battery/time-mode

[David Reitter]

(customize-mark-to-save 'display-battery-mode)

is always t even though now change was made because the standard- 
value property is nil / not set. It should probably be (nil). One  
consequence of this is that menu-bar-save-options always saves the  
customizations, even though they haven't changed.

It works fine for, e.g., `show-paren-mode'.

This problem occurs both with `display-battery-mode' and `display- 
time-mode'.





--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and  
support the Aquamacs Project!

Re: standard-value of display-battery/time-mode

[Luc Teirlinck]

David Reitter wrote:

   (customize-mark-to-save 'display-battery-mode)

   is always t even though now change was made because the standard- 
   value property is nil / not set. It should probably be (nil).

`display-battery-mode' is autoloaded.  This means that it is defined
with `defvar' in loaddefs.el.  The standard-value property remains nil
until the defcustom is evaluated, when it becomes (nil).

   It works fine for, e.g., `show-paren-mode'.

Then your .emacs must load paren.

`emacs -q', then:

ELISP> (get 'show-paren-mode 'standard-value)
nil
ELISP> (load "paren")
t
ELISP> (get 'show-paren-mode 'standard-value)
(nil)

ELISP> 

Sincerely,

Luc.

Re: standard-value of display-battery/time-mode

[David Reitter]

On 19 Feb 2006, at 00:31, Luc Teirlinck wrote:

>    (customize-mark-to-save 'display-battery-mode)
>
>    is always t even though now change was made because the standard-
>    value property is nil / not set. It should probably be (nil).
>
> `display-battery-mode' is autoloaded.  This means that it is defined
> with `defvar' in loaddefs.el.  The standard-value property remains nil
> until the defcustom is evaluated, when it becomes (nil).

OK, so something like menu-bar-options-save should contain a few  
require's then.
I've written something that'll automatically save the options at the  
end of an Emacs session.The user is asked whether to actually do that  
if they have changed. Obviously, I don't want to ask if there is no  
change, which means I'll need to load the appropriate libraries at  
that point.

Maybe that's something that menu-bar-options-save should do as well,  
because as it stands now, the customizations are always written to  
file, whether there have been changes or not (unless all those  
libraries have been loaded).

Re: standard-value of display-battery/time-mode

[Richard M. Stallman]

    `display-battery-mode' is autoloaded.  This means that it is defined
    with `defvar' in loaddefs.el.  The standard-value property remains nil
    until the defcustom is evaluated, when it becomes (nil).

Does this mean there is no bug?

Re: standard-value of display-battery/time-mode

[Luc Teirlinck]

Richard Stallman wrote:

       `display-battery-mode' is autoloaded.  This means that it is defined
       with `defvar' in loaddefs.el.  The standard-value property remains nil
       until the defcustom is evaluated, when it becomes (nil).

   Does this mean there is no bug?

No, it means that the files necessary to evaluate the defcustoms
should be loaded.  This morning, Chong Yidong added:

   (custom-load-symbol symbol)

to the `customize-mark-to-save' code (Rev 1.120 to custom.el), which
should have done that, but then he took it back out in the next
revision.  I do not know what the problem was that necessitated this
revert.

Sincerely,

Luc.

Re: standard-value of display-battery/time-mode

[Chong Yidong]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> No, it means that the files necessary to evaluate the defcustoms
> should be loaded.  This morning, Chong Yidong added:
>
>    (custom-load-symbol symbol)
>
> to the `customize-mark-to-save' code (Rev 1.120 to custom.el), which
> should have done that, but then he took it back out in the next
> revision.  I do not know what the problem was that necessitated this
> revert.

custom-load-symbol does not work for all variables concerned.  At
first, I thought all the relevant variables have 'custom-load property
(which tells custom-load-symbol what to load), but I was wrong.  I
don't know what the criteria is that variables are given
'custom-load---is it only if the variable name matches the custom
group name?

So I am trying to think of a better solution.

Maybe we should explicitly load those defcustoms that appear in the
menu-bar, in menu-bar.el.

Re: standard-value of display-battery/time-mode

[Luc Teirlinck]

Chong Yidong wrote:

   custom-load-symbol does not work for all variables concerned.  At
   first, I thought all the relevant variables have 'custom-load property
   (which tells custom-load-symbol what to load), but I was wrong.  I
   don't know what the criteria is that variables are given
   'custom-load---is it only if the variable name matches the custom
   group name?

You did not give any examples.  Are these options that are neither
autoloaded nor preloaded?  A magic autoload cookie should, I believe,
write a line of the form:

(custom-autoload (quote show-paren-mode) "paren")

in loaddefs.el.  So I believe that it should suffice to add that
custom-load-symbol call back and put in ###autoload's for all options
for which it fails to work.

Sincerely,

Luc.

Re: standard-value of display-battery/time-mode

[Chong Yidong]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Chong Yidong wrote:
>
>    custom-load-symbol does not work for all variables concerned.  At
>    first, I thought all the relevant variables have 'custom-load property
>    (which tells custom-load-symbol what to load), but I was wrong.  I
>    don't know what the criteria is that variables are given
>    'custom-load---is it only if the variable name matches the custom
>    group name?
>
> You did not give any examples.  Are these options that are neither
> autoloaded nor preloaded?  A magic autoload cookie should, I believe,
> write a line of the form:
>
> (custom-autoload (quote show-paren-mode) "paren")
>
> in loaddefs.el.  So I believe that it should suffice to add that
> custom-load-symbol call back and put in ###autoload's for all options
> for which it fails to work.

I guess there isn't a problem after all, so I checked in the change.
Thanks.