Bug in Custom

[Luc Teirlinck <teirllm@dms.auburn.edu>]

I reported this bug a month and a half ago, but it is still present.
When I first reported it, the person who introduced the bug did
apparently not even read my explanations and declared the bug to be a
"feature".  In the interest of Custom users, it would be good if
somebody else (Richard?) tried to understand my arguments of why this
really is a bug.

I CC-ed Per in case he is interested.

  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.

To which Chong Yidong replied:

   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.

I already refuted this a month and a half ago, but in the hope that
somebody else might be willing to actually try to understand why
this makes no sense, I will try one last time.

If somebody uses setq on a variable in his .emacs, he should not use
"Erase Customization" in a Custom buffer, because it will not work, so
we do no have to worry about that case.  However if somebody sets
variables for the current session only, then he can do that
alternatively through Custom buffers and through other means (say
using interactive functions such as minor modes or, say, fringe-mode,
or using ielm).  The choice between the two depends exclusively on
what is more convenient at the time.  The user should be able to get
the standard value back using "Erase Customization", not the value he
last set when it was more convenient not to use Custom.

Even more importantly, if some Lisp code sets the variable behind
the user's back, then the user should be able to get the standard
value back using "Erase Customization".  The fact that he has to do
that is already bad enough.  Custom should not make things a lot
worse, by not even allowing the user to do that,

The new "feature" is nowhere documented.  It is not mentioned in the
NEWS under `** Customize changes' and (emacs)Changing a Variable still
says:

`Erase Customization'
     This sets the variable to its standard value, and updates the text
     accordingly.  This also eliminates any saved value for the
     variable, so that you will get the standard value in future Emacs
     sessions.

The problem is caused by the `changed' theme, which tries to restore
the last value set _outside_ Custom.  This theme makes no sense.
Themes do not override options set explicitly by the user using
Custom.  So they should definitely not override options set by the
user by other means (which would make the `changed' theme irrelevant).
The choice between using Custom or other means is normally made based
on convenience and nothing else.

I believe that the "feature" was introduced by the following change:

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

   ...

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


Even if it is agreed that the above is a bug, I will not fix it
myself.  I got so disillusioned by the fact that Custom is apparently
being heavily redesigned (in a feature freeze, shortly before a
release) by somebody who does not understand Custom well enough to
understand that the above really _is_ a bug, as well as by the
reaction I got when I first reported the bug, that I no longer use
Custom or have any interest in it.  To me this it seems like Custom is
bound to be destroyed by the pathologically anti-modular Custom Themes
code, so any further work on it by me seems to be a waste of my time.
I just reported the above one last time for the sake of Custom users.

Sincerely,

Luc.