Bug in Custom

Bug in Custom

[Luc Teirlinck]

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.

Re: Bug in Custom

[Lennart Borgman]

Luc Teirlinck wrote:
> 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.
>   
I agree this is a bug. A serious bug.

Re: Bug in Custom

[Luc Teirlinck]

>From my previous message:

   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.

Actually, I did not check this carefully and I may have been confusing
with something else (from the discussion a month and a half ago) when
I wrote this.  The bug/"feature" may have been caused by some other
change, but it is definitely related to the `changed' theme.

Sincerely,

Luc.

Re: Bug in Custom

[Chong Yidong]

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

As I explained before, it was Richard who, some time last year,
decided that disabling Custom themes will bring back old values set
outside of Customize; maybe you missed this explanation (or maybe you
did not even read it).

I am fine with getting rid of the `changed' theme, if Richard decides
to revert his earlier decision.  I can try to find the discussion if
it's of interest.

Re: Bug in Custom

[Luc Teirlinck]

Chong Yidong wrote:

   As I explained before, it was Richard who, some time last year,
   decided that disabling Custom themes will bring back old values set
   outside of Customize; maybe you missed this explanation (or maybe you
   did not even read it).

No, I _did_ read that.  However, this does not mean that Richard also
decided that a consequence of that decision, the bug I reported (of
which I do not know whether you still consider it a feature), made
sense.  My best guess is that Richard did not realize that his
decision had this consequence.

When _new_ evidence emerges that a decision was bad, one has to be
willing to reconsider that decision.

The decision had bad consequences when applied to the user theme (the
bug I reported).  The consequences are bad for other Themes for the
same reasons.

As I already mentioned in my previous message, I believe that it would
be better if Themes did not override rogue values.  They do not
override values set by the user through Custom either.  Setting values
through Custom or outside Custom is a matter of what is most
convenient at the time and _not_ a statement of how important the
value is or how "sticky" it should be.

Custom users who see that Themes do not override values set by Custom
would be very surprised if they did override values the user set
outside Custom.  Many users will not even remember whether the values
they have set were last set using Custom or outside Custom.  Also even
when they remember how they set them (menubar, set-variable), they
might not even know whether that counts as set through Custom or not.

Sincerely,

Luc.

Re: Bug in Custom

[Robert J. Chassell]

   I reported this bug a month and a half ago, but it is still present.

Someone could (partially) fix the bug by revising the words "Erase
Customization" in the `State' menu to "Change this Value to Previous".

The bug occurs because of different ways people think of the notion of
"Customization".  Most people that I know think of what you do in this
buffer as similar to evaluating

    (setq fill-column 72)

in a *scratch*, .emacs, or other buffer, but with a different
function.  (In this case, `custom-set-variables'.)  In addition, they
think of "Customization" as something you do with that different
function (or with `custom-set-faces').

That is to say, "Customization" in this context is not what you do
when you evaluate `(setq fill-column 72)' in your `user-init-file', it
is what you do when you evaluate

    (custom-set-variables '(fill-column 72))

So "Erase Customization" does exactly what most of the people I know
expect.  Moreover, it fits what RMS has said to expect.

Because of the different understandings of what `customization' means,
you are suggesting that evaluating a `custom-set-variables' expression
should change values set by evaluating a `setq' expression in your
existing customization file.  

In addition, you are suggesting that another way of saying "customize"
should be "evaluating a `setq' expression".


(info "(emacs)Changing a Variable")    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.

Yes, this is clearly a bug.

The action does not set the variable to its standard value; the action
changes it to what ever it was before using the `custom-set-variables'
function.  The new value is only sometimes its standard value.  The
documentation should be reworded.

Incidently, the second sentence in the documentation for
`Custom-reset-standard' should also be reworded, too.  The first line
of that documentation is accurate:

  Erase all customization (either current or saved) for the group members.

But the second line is not:

    The immediate result is to restore them to their standard values.


Indeed, since many new people will think that customization refers to
the effects of evaluating a `setq' expression as well as a
`custom-set-*' expression, perhaps the word `customization' and its
cognates should all be changed.  That would mean, for example,
changing the phrase "customization buffer" to "novices' change
buffer".  It could mean changing `custom' to
`novices-special-evaluation'.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Bug in Custom

[Richard Stallman]

I don't think this is a bug.  It is a choice between two behaviors,
each of which is in some ways right, but neither of which is ideal.

I won't reopen this design question now -- I don't have time.  So I
will stick with the decision I made, back when I did consider the
question.

Let's please move towards the release.  There are a few files of the
Lisp Manual that ought to be checked again; would someone please do
that?

Re: Bug in Custom

[Per Abrahamsen]

Mixing Lisp and Customize for modifying the same option will always
result in surprising behavior, no matter what semantics is chosen.

My only advice would be: don't do that.

Re: Bug in Custom

[Luc Teirlinck]

Per Abrahamsen wrote:

   Mixing Lisp and Customize for modifying the same option will always
   result in surprising behavior, no matter what semantics is chosen.

   My only advice would be: don't do that.

That is true now, after the latest changes.  Before that, setting a
value that was setq-ed in .emacs through Custom had indeed unreliable
consequences (and it still does).  However, you could perfectly
reliably experiment with new values for an option, alternately through
Custom and through other interactive means and after your
experimentation set it back to the standard value using "Erase
Customization".  I used to do this routinely without any problems.
However now this does not work any more, because "Erase Customization"
now sets the option to some essentially random previous value.  This
makes experimenting with various values for an option far less
convenient than it used to be.

Sincerely,

Luc.