Bug in Custom apparently due to Custom Themes.

Bug in Custom apparently due to Custom Themes.

[Luc Teirlinck]

Use a .emacs containing only the single line:

(blink-cursor-mode 0)

Do `M-x customize-option desktop-save-mode RET'

Enable the option and save for future sessions.

Exit Emacs, using ~/ as the directory for desktop to save in.
Start Emacs again.

Do `M-x customize-option desktop-save-mode RET'.

Choose "Erase Customization" from the State menu, for instance using
the mouse.  That should reset the State to STANDARD.  Instead we see:

CHANGED outside Customize; operating on it here may be unreliable.

Edebugging custom-variable-state-set suggests that this bug is due to
the fact that the theme-value property of desktop-save-mode at this
stage is ((changed nil)).  I am not using any Custom Themes so I
should not be encountering any code related to Custom Themes.  Since I
know that the way I would fix this bug would be considered
unacceptable, somebody else will have to take a look at it.

Sincerely,

Luc.

Re: Bug in Custom apparently due to Custom Themes.

[Luc Teirlinck]

I should have mentioned that the bug I described does not occur in a
CVS version I have lying around from 2005-02-07, so the bug must have
been introduced since then.

Sincerely,

Luc.

Re: Bug in Custom apparently due to Custom Themes.

[Luc Teirlinck]

It would appear that the code which, according to my edebugging,
produces the bug was introduced by this change:

2005-12-23  Chong Yidong  <cyd@stupidchicken.com>

   ...

   (custom-variable-state-set, custom-face-state-set):
   Check theme-value instead of saved-value.

   ....

So there is a definite probability that a similar problem exists for
custom-face-state-set too, although I did not check this.

Sincerely,

Luc.

Re: Bug in Custom apparently due to Custom Themes.

[Chong Yidong]

> Use a .emacs containing only the single line:
>
> (blink-cursor-mode 0)
>
> Do `M-x customize-option desktop-save-mode RET'
>
> Enable the option and save for future sessions.
>
> Exit Emacs, using ~/ as the directory for desktop to save in.
> Start Emacs again.
>
> Do `M-x customize-option desktop-save-mode RET'.
>
> Choose "Erase Customization" from the State menu, for instance using
> the mouse.  That should reset the State to STANDARD.  Instead we see:
>
> CHANGED outside Customize; operating on it here may be unreliable.

This should be fixed.

Re: Bug in Custom apparently due to Custom Themes.

[Chong Yidong]

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

> It would appear that the code which, according to my edebugging,
> produces the bug was introduced by this change:
>
> 2005-12-23  Chong Yidong  <cyd@stupidchicken.com>
>
>    ...
>
>    (custom-variable-state-set, custom-face-state-set):
>    Check theme-value instead of saved-value.

I believe this code is correct.  I made a fix elsewhere.

Re: Bug in Custom apparently due to Custom Themes.

[Luc Teirlinck]

   > 2005-12-23  Chong Yidong  <cyd@stupidchicken.com>
   >
   >    ...
   >
   >    (custom-variable-state-set, custom-face-state-set):
   >    Check theme-value instead of saved-value.

   I believe this code is correct.  I made a fix elsewhere.

Your change indeed fixed the bug I reported.  But the code I
referenced does not seem correct anyway.  I first found the bug I
reported.  Then I edebugged my way to code that seemed to have obvious
problems.  I incorrectly guessed that these problems were responsible
for the bug I was investigating.  But they do produce other bugs, of
which I will now give an example.

Start Emacs, assuming that fill-column is at its standard value of 70
and do

M-: (setq-default fill-column 71)

`M-x customize-option fill-column RET'

Edit to 72 and set for current session, using the State Menu.

Then choose "Erase Customization" from the State Menu.

The value should now be 70 and the State STANDARD.

Instead, the value is 71 and we see:

CHANGED outside Customize; operating on it here may be unreliable.

Sincerely,

Luc.

Re: Bug in Custom apparently due to Custom Themes.

[Chong Yidong]

> Start Emacs, assuming that fill-column is at its standard value of 70
> and do
>
> M-: (setq-default fill-column 71)
>
> `M-x customize-option fill-column RET'
>
> Edit to 72 and set for current session, using the State Menu.
>
> Then choose "Erase Customization" from the State Menu.
>
> The value should now be 70 and the State STANDARD.
>
> Instead, the value is 71 and we see:
>
> CHANGED outside Customize; operating on it here may be unreliable.

I don't see the problem: the value 71 is the last value that
fill-column had before it was changed with customize.  That's why
erasing customizations brings back this value.

Re: Bug in Custom apparently due to Custom Themes.

[Luc Teirlinck]

Chong Yidong wrote:

   > Start Emacs, assuming that fill-column is at its standard value of 70
   > and do
   >
   > M-: (setq-default fill-column 71)
   >
   > `M-x customize-option fill-column RET'
   >
   > Edit to 72 and set for current session, using the State Menu.
   >
   > Then choose "Erase Customization" from the State Menu.
   >
   > The value should now be 70 and the State STANDARD.
   >
   > Instead, the value is 71 and we see:
   >
   > CHANGED outside Customize; operating on it here may be unreliable.

   I don't see the problem: the value 71 is the last value that
   fill-column had before it was changed with customize.  That's why
   erasing customizations brings back this value.

Do you use Custom at all?  The problem is so obvious that I do not
know what there is to explain.  "Erase Customization" is supposed to
restore the standard value (or themed value if there are themes) and
_not_ the last _rogue_ value assigned to the variable, which may have
been assigned ages ago, and changed twenty times through Custom since.
That value is meaningless, which is why that `changed' theme is
completely meaningless and should be eliminated.

What I described above constitutes an incompatible change, which
eliminates completely essential and well documented functionality
(reverting to the default) and replaces it with nonsensical behavior.
It is a serious bug.

Sincerely,

Luc.

Re: Bug in Custom apparently due to Custom Themes.

[Chong Yidong]

> Do you use Custom at all?  The problem is so obvious that I do not
> know what there is to explain.  "Erase Customization" is supposed to
> restore the standard value (or themed value if there are themes) and
> _not_ the last _rogue_ value assigned to the variable, which may have
> been assigned ages ago, and changed twenty times through Custom since.
> That value is meaningless, which is why that `changed' theme is
> completely meaningless and should be eliminated.

On the other hand, Richard decided, long ago, that it is consistent to
bring back old rogue values when a Custom theme is disabled.  The
values set by customize are also considered a custom theme, one that
always has precedence.

By the way, please try to be civil; being obnoxious is not productive
in these email discussions, even when you think you know everything
and the other party knows nothing.