Bug, probably related to Custom Themes.

Bug, probably related to Custom Themes.

[Luc Teirlinck]

The following bug is a regression.  It does not occur in Emacs 21.3.

I can not describe this using `emacs -q', since it involves saving in
your init file.

Do `M-x customize-group RET initialization'.

I assume that `inhibit-splash-screen' is at its standard setting (nil).
Toggle.  Save for future sessions.  Erase Customization.  Result:

(custom-reset-variables
 '(inhibit-splash-screen nil))

is written into one's Custom file, just before the
custom-set-variables form.  First of all, I do not know what those
lines are trying to accomplish, but what we just did is supposed to be
a no-op.  Therefore if that code does _anything_, it is a bug.  If it
does nothing, why is it there?

Worse to come.

I assume that `inhibit-default-init' is at its standard setting (nil).
Toggle.  Save for future sessions.  Erase Customization.
Now the above lines are gone and replaced with a bunch of whitespace
and then:

(custom-reset-variables
 '(inhibit-default-init nil))

As we do similar stuff for other options we always keep that
`custom-reset-variables' for the last one with the amount of leading
whitespace going to infinity.

Exactly the same stuff happens for faces.

What is going on here?

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

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

> I assume that `inhibit-splash-screen' is at its standard setting (nil).
> Toggle.  Save for future sessions.  Erase Customization.  Result:
>
> (custom-reset-variables
>  '(inhibit-splash-screen nil))
>
> is written into one's Custom file, just before the
> custom-set-variables form.  First of all, I do not know what those
> lines are trying to accomplish, but what we just did is supposed to be
> a no-op.  Therefore if that code does _anything_, it is a bug.

Why is it a bug?  You did click on "Save for future sessions", which
writes the customizations to .emacs.  The tooltip for "Erase
Customization" says "Un-customize all values in this buffer" (i.e.,
the Custom buffer).  I wouldn't expect this to write to .emacs.

>  If it does nothing, why is it there?

If you mean the "Erase Customization" button, I assume it's to reset
all the items in the Custom buffer to their default (uncustomized)
values.  This does not imply making them take effect (that's what "Set
For Current Session" and "Save for Future Sessions" is for.)

On the other hand, it's not clear to me what the "Reset to Current"
button is supposed to do.  I'm guessing it resets items to values that
may be changed outside of Customize.  I don't think this serves much
purpose except to confuse newbies, who wouldn't be changing stuff
outside Customize anyway.

Probably "Erase Customization" should be renamed "Reset to Default".

> The following bug is a regression.  It does not occur in Emacs 21.3.

In Emacs 21.3, Erase Customization doesn't write to .emacs either.  (I
really don't see how this issue is related to Custom Themes, btw.)

It would be nice if Custom is smart enough to detect when a variable
is being set back to its default value, and omit that variable in
custom-set-variables.  But this would be a new feature, not a bugfix.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Chong Yidong wrote:

   I wouldn't expect this to write to .emacs.

The bug is that it _does_ write into your Custom file.  If it does not
do that for you then it must somehow depend on my customizations, but
none of my customizations is supposed to have that effect, so there
must be a bug _somewhere_.  (I use a separate custom file.)  The
problem is that the bug has to do with writing into one's Custom file,
so `emacs -q' is meaningless.  If the bug does not happen for other
people, I could try to start out with an empty Custom file.

   >  If it does nothing, why is it there?

   If you mean the "Erase Customization" button,

No, I mean the lines:

(custom-reset-variables
 '(inhibit-default-init nil))

in my Custom file.

   (I really don't see how this issue is related to Custom Themes,
   btw.)

It is just a guess.  I said _probably_ related to Custom themes.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

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

>    >  If it does nothing, why is it there?
>
>    If you mean the "Erase Customization" button,
>
> No, I mean the lines:
>
> (custom-reset-variables
>  '(inhibit-default-init nil))
>
> in my Custom file.

OK, now I see what you mean.

>    (I really don't see how this issue is related to Custom Themes,
>    btw.)
>
> It is just a guess.  I said _probably_ related to Custom themes.

Why do you think it is probably related to Custom Themes?

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

   Why do you think it is probably related to Custom Themes?

The documentation of Custom themes in the Emacs manual leaves many
important questions unanswered.

For instance, consider the following.

If somebody puts `(load-theme 'foo)' in their .emacs and the
custom-set-variables form has no setting for option bar and if no
"rogue" setting for bar overrides foo, then bar gets the value
specified by foo.  No problem.

If now the user saves another value for bar in a Custom buffer for
future sessions, then from now on that saved value overrides foo's
value.  No problem.

But the user has some bad experiences with the new value and wants to
get rid of it.  He chooses "Erase Customization" in a Custom buffer.

_Now_ what is supposed to happen?  Do we restore the value set by foo
or the "standard" value that would be in effect if there were no themes?

I have the impression that the purpose of the:

(custom-reset-variables
 '(bar nil))

is to override foo's value and restore the no-themes default.  If this
is really the intent, then not only are there bugs in the
implementation, the intent itself can not possibly be implemented in
a consistent way.  It is not because somebody long ago experimented
with some value for bar and then erased that customization that from
there on forward, any value for bar set by any new theme the user
might ever load in the future should be overridden.

Loading a theme means installing a new set of defaults.  "Erase
Customization" should restore the theme value.  If the user wants the
no-themes default, he should set and save bar in a Custom buffer to
the no-themes default, thereby making the no-theme default the user
theme value which explicitly overrides any theme, present or future.
That is the only way one can be consistent.  It is the only way to
avoid that somebody who does not use any themes whatsoever (other than
the user one) gets his Custom file written full with stuff that not
only makes his Custom file longer and more messy, but that moreover
may override themes he might want to use in the future (whereas he
never _wanted_ to override the value set by these themes).

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    But the user has some bad experiences with the new value and wants to
    get rid of it.  He chooses "Erase Customization" in a Custom buffer.

    _Now_ what is supposed to happen?  Do we restore the value set by foo
    or the "standard" value that would be in effect if there were no themes?

It should restore the value set by foo, because that's the only
consistent meaning.  It should get rid of "user" customizations,
but it cannot get rid of theme values.

    Loading a theme means installing a new set of defaults.  "Erase
    Customization" should restore the theme value.  If the user wants the
    no-themes default, he should set and save bar in a Custom buffer to
    the no-themes default, thereby making the no-theme default the user
    theme value which explicitly overrides any theme, present or future.
    That is the only way one can be consistent.

I agree.

In what way does the current behavior differ from that?

    I have the impression that the purpose of the:

    (custom-reset-variables
     '(bar nil))

    is to override foo's value and restore the no-themes default.

I'm not sure what that ought to do.  Looking at the doc string, it is
not clear that this case was intended to be used at all.

Thus, if it doesn't do anything useful, and it's not easy to make it
do anything useful, we could simply make it an error.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

   I agree.

   In what way does the current behavior differ from that?

I have the impression the the current code usually restores the theme
value and sometimes the no-theme default.  I believe that it tries to
always restore the no-theme default (which it should not), but that,
because of severe bugs, it seldom succeeds.  It is impossible to know
for sure what the code is actually _trying_ to do, however.  It appears
to be very buggy.

The patch below will assure that the theme value is consistently
restored.  I can install if desired.

===File ~/cus-edit-diff=====================================
*** cus-edit.el	19 Dec 2005 16:46:48 -0600	1.250
--- cus-edit.el	22 Dec 2005 13:35:11 -0600	
***************
*** 4031,4040 ****
    "Save all customized variables in `custom-file'."
    (save-excursion
      (custom-save-delete 'custom-load-themes)
-     (custom-save-delete 'custom-reset-variables)
      (custom-save-delete 'custom-set-variables)
      (custom-save-loaded-themes)
-     (custom-save-resets 'theme-value 'custom-reset-variables nil)
      (let ((standard-output (current-buffer))
  	  (saved-list (make-list 1 0))
  	  sort-fold-case)
--- 4031,4038 ----
***************
*** 4095,4103 ****
  (defun custom-save-faces ()
    "Save all customized faces in `custom-file'."
    (save-excursion
-     (custom-save-delete 'custom-reset-faces)
      (custom-save-delete 'custom-set-faces)
-     (custom-save-resets 'theme-face 'custom-reset-faces '(default))
      (let ((standard-output (current-buffer))
  	  (saved-list (make-list 1 0))
  	  sort-fold-case)
--- 4093,4099 ----
***************
*** 4149,4180 ****
        (unless (looking-at "\n")
  	(princ "\n")))))
  
! (defun custom-save-resets (property setter special)
!   (let (started-writing ignored-special)
!     ;; (custom-save-delete setter) Done by caller
!     (let ((standard-output (current-buffer))
! 	  (mapper `(lambda (object)
! 		    (let ((spec (car-safe (get object (quote ,property)))))
! 		      (when (and (not (memq object ignored-special))
! 				 (eq (nth 0 spec) 'user)
! 				 (eq (nth 1 spec) 'reset))
! 			;; Do not write reset statements unless necessary.
! 			(unless started-writing
! 			  (setq started-writing t)
! 			  (unless (bolp)
! 			    (princ "\n"))
! 			(princ "(")
! 			(princ (quote ,setter))
! 			(princ "\n '(")
! 			(prin1 object)
! 			(princ " ")
! 			(prin1 (nth 3 spec))
! 			(princ ")")))))))
!       (mapc mapper special)
!       (setq ignored-special special)
!       (mapatoms mapper)
!       (when started-writing
! 	(princ ")\n")))))
  
  (defun custom-save-loaded-themes ()
    (let ((themes (reverse (get 'user 'theme-loads-themes)))
--- 4145,4176 ----
        (unless (looking-at "\n")
  	(princ "\n")))))
  
! ;; (defun custom-save-resets (property setter special)
! ;;   (let (started-writing ignored-special)
! ;;     ;; (custom-save-delete setter) Done by caller
! ;;     (let ((standard-output (current-buffer))
! ;; 	  (mapper `(lambda (object)
! ;; 		    (let ((spec (car-safe (get object (quote ,property)))))
! ;; 		      (when (and (not (memq object ignored-special))
! ;; 				 (eq (nth 0 spec) 'user)
! ;; 				 (eq (nth 1 spec) 'reset))
! ;; 			;; Do not write reset statements unless necessary.
! ;; 			(unless started-writing
! ;; 			  (setq started-writing t)
! ;; 			  (unless (bolp)
! ;; 			    (princ "\n"))
! ;; 			(princ "(")
! ;; 			(princ (quote ,setter))
! ;; 			(princ "\n '(")
! ;; 			(prin1 object)
! ;; 			(princ " ")
! ;; 			(prin1 (nth 3 spec))
! ;; 			(princ ")")))))))
! ;;       (mapc mapper special)
! ;;       (setq ignored-special special)
! ;;       (mapatoms mapper)
! ;;       (when started-writing
! ;; 	(princ ")\n")))))
  
  (defun custom-save-loaded-themes ()
    (let ((themes (reverse (get 'user 'theme-loads-themes)))
============================================================

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

       Loading a theme means installing a new set of defaults.  "Erase
       Customization" should restore the theme value.  If the user wants the
       no-themes default, he should set and save bar in a Custom buffer to
       the no-themes default, thereby making the no-theme default the user
       theme value which explicitly overrides any theme, present or future.
       That is the only way one can be consistent.

   I agree.

   In what way does the current behavior differ from that?

After some checking, things are really bad.  The behavior is that with
_and_ without my patch, "Erase Customization" resets to the no-theme
default _for the current session_.  Hence my patch does not completely
fix the bug.

I suggest that, until a real fix would be installed (which will take
time), we install my patch anyway, because it will at least prevent
CVS user's .emacs from getting messed up (_even_ if they use no
themes).  My patch will be part of any real fix anyway, it just is not
the complete fix.  For people who do not use themes, it _is_ a
complete fix.

The "Themes" code is completely and hopelessly messed up.  It needs to
be rewritten from scratch.  Themes should change the standard-value
property, not the saved-value one, since they change the default
values.  There should be no user "theme", but there probably should be a
standard theme.  The "Themes" code should not try to rewrite cus-edit.
If `load-theme' and `disable-theme' correctly update the
standard-value, there is no need for Custom to know anything about
themes.  Except for one thing: there needs to be a "theme" custom
state, just to tell the user in a Custom buffer that the value was set
by a theme (other than the standard theme).  `load-theme' and
'disable-theme' should keep track of that, Custom should not have to
worry about it.  If the user uses no themes, the "Themes" code should
not be loaded at all.

This way, you do not need to understand the Themes code to understand
the Custom code (which hence gets more transparent) and bugs in the
Themes code can never mess up all of Custom.

The Themes code itself would be a lot simpler than the contorted
current mess, which nobody is able to understand and which does not
work.

For Themes to be able to handle hooks and list-vars in any
satisfactory way, the bugs in Custom concerning hooks and list-vars
would need to be fixed.

I believe that trying to fix the current Themes code is hopeless.  It
_needs_ to be rewritten from scratch.  Either we should delay
introduction of Themes until Emacs 23 (this is what I personally
recommend), or we should completely rewrite it (and probably fix the
hook bugs in Custom too) before the release.  If we want to do the
latter, we are talking about at the very least six months before a
pretest could start, probably more than a year.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

       Loading a theme means installing a new set of defaults.  "Erase
       Customization" should restore the theme value.  If the user wants the
       no-themes default, he should set and save bar in a Custom buffer to
       the no-themes default, thereby making the no-theme default the user
       theme value which explicitly overrides any theme, present or future.
       That is the only way one can be consistent.

   I agree.

   In what way does the current behavior differ from that?

After careful checking my suspicions turned out to be completely
correct.  The current behavior (without my patch, which _partially_
fixes it) is as follows.

If you save a "setting" (to use the brand new terminology) and then
choose "Erase Customization" for the same setting, the no-themes
default gets restored for the current session and for future sessions
_until_ you choose "Erase Customization" for some _other_ setting.
After that, the no-themes default stays into effect for the remainder
of that session but for sessions started after that, the theme value is
restored.  This, of course, makes no sense whatsoever.  This is no
surprise.  Very few things in the current Themes code make any sense
whatsoever.

       I have the impression that the purpose of the:

       (custom-reset-variables
	'(bar nil))

       is to override foo's value and restore the no-themes default.

   I'm not sure what that ought to do.  Looking at the doc string, it is
   not clear that this case was intended to be used at all.

As I suspected, it does restore the no-themes default (I checked).

As I already said in an earlier message, we should get rid of the
current Themes code and replace it with something that makes sense.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    If you save a "setting" (to use the brand new terminology) and then
    choose "Erase Customization" for the same setting, the no-themes
    default gets restored for the current session and for future sessions
    _until_ you choose "Erase Customization" for some _other_ setting.
    After that, the no-themes default stays into effect for the remainder
    of that session but for sessions started after that, the theme value is
    restored.

Yidong, could you fix this?  Erase Customization should remove the
`user' customization, and doing that consistently would put the theme
value back into effect.

	       This, of course, makes no sense whatsoever.  This is no
    surprise.  Very few things in the current Themes code make any sense
    whatsoever.

Please don't exaggerate the negative.  Despite the existence of a few
bugs such as this one, the custom themes code basically works.
Now we'll fix this bug, and it will work even better.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

   Please don't exaggerate the negative.  Despite the existence of a few
   bugs such as this one, the custom themes code basically works.

Its basic design is completely flawed, for the reasons I explained.

   Now we'll fix this bug, and it will work even better.

Suppose the bug I reported would be fixed.  That would not be the end
of the trouble.  

After selecting "Erase Customization", the State button will still say
"SAVED and set" (instead of the expected "STANDARD") and the "Erase
Customization" part of the State Menu will still be active.  (It
should _not_ be, since it will have no further effect when selected
again.)  All of this is very confusing to the user.  When a value is
set by a theme, the State button should not say "SAVED and set" and
the "Erase Customization" part of the State menu should not be
enabled.  Better than "SAVED and set" would be "STANDARD", still better
"THEME value".  Themes should set the standard-value property, not the
saved-value one and they should set the Custom state to 'standard, or
even better 'theme, not to 'saved.

With the current Themes code, any attempt to fix bugs in the Themes
code can badly mess up Custom for everybody, including people who do
not use Themes at all.  (It _did_ happen in the case of the bug I
reported.)  This should not happen.  The Themes code should be in a
separate file, which is not even loaded if you do not use themes.  It
should not be intertwined with Custom as it is now.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

No need to write these long essays.  I'll take a look at the problem.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

   Yidong, could you fix this?  Erase Customization should remove the
   `user' customization, and doing that consistently would put the theme
   value back into effect.

That treats a symptom instead of the _real_ underlying bug.  I have
already given one more example of a "surface bug" that is caused by
the same underlying bug: if a setting is set by a theme, the "Erase
Customization" item of the State Menu is enabled, whereas it should
not be, because it is not going to have any effect (which is confusing
to the user, because the State message says and keeps saying:
"SAVED and set").

That second surface bug is still very closely realted to the original
one.  I will now describe a third surface bug that is, at first view,
completely unrelated.

I load a theme file containing:

 '(column-number-mode t)

Then I disable column-number-mode via the Options menu in the menu bar
and then save my options _using the "Save Options" menu bar item_.
column-number-mode is disabled for the current session, but if I start
a new session column-number-mode is enabled again even though I saved
my customization to disable it.

What happens is that, since I just set column-number-mode to its
standard-value, Custom thought that it just had to erase a line in my
custom-set-variables form (that was not there).  Instead, Custom should
have written a line in my custom-set-variables form explicitly setting
column-number-mode to nil, to override my theme.

The above describes two more bugs in addition to the original one.
 
What is really going on here?  We agreed that we should treat Theme
values as alternative default values.  It is the only way to get
consistent behavior.  But we tell Custom that the Theme value is a
user customization and that the default value is the no-themes
default, by storing the theme value in saved-value instead of
standard-value.  Obviously whenever Custom checks the value of
standard-value, a bug is likely to result.  I listed three bugs of
this type.  I am pretty sure that you can find a fourth and a fifth
and so on, just by grepping for customized-value in the Emacs source code.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

>From my earlier message:

   Obviously whenever Custom checks the value of standard-value, a bug
   is likely to result.  I listed three bugs of this type.  I am
   pretty sure that you can find a fourth and a fifth and so on, just
   by grepping for customized-value in the Emacs source code.

Obviously, one would have to grep for `standard-value', not
`customized-value'. 

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

I checked in a fix.  Please see if it works.

> I load a theme file containing:
>
>  '(column-number-mode t)
>
> Then I disable column-number-mode via the Options menu in the menu bar
> and then save my options _using the "Save Options" menu bar item_.
> column-number-mode is disabled for the current session, but if I start
> a new session column-number-mode is enabled again even though I saved
> my customization to disable it.

Maybe the "Save Options" menu bar entry should unconditionally save
all these options.  The current behavior, which is to check the
saved-value of the option against its default-value, doesn't seem to
be necessary.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Chong Yidong wrote:

   Maybe the "Save Options" menu bar entry should unconditionally save
   all these options.  The current behavior, which is to check the
   saved-value of the option against its default-value, doesn't seem to
   be necessary.

Then you would get the opposite problem: hardcoding a bunch of
settings to their default values, thereby overriding future themes,
without the user having asked for that.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Why did you change the position of the whole buffer "Erase
Customization" button?  It forms a unit with the two Reset buttons and
hence it is more logical to put them on the same line.  Also in the
old order, the whole buffer buttons were in the same order as in the
State Menu, which made sense.

This change seems to be completely unrelated to the bugs we are discussing.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

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

> Why did you change the position of the whole buffer "Erase
> Customization" button?  It forms a unit with the two Reset buttons and
> hence it is more logical to put them on the same line.

That was a change that got mixed up with the rest of my changes.

Anyhow, it doesn't really form a unit with the other two "Reset"
buttons, since those only reset the customize buffer.  Erase
Customization is really a save command, since it writes to
custom-file.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    Why did you change the position of the whole buffer "Erase
    Customization" button?  It forms a unit with the two Reset buttons and
    hence it is more logical to put them on the same line.  Also in the
    old order, the whole buffer buttons were in the same order as in the
    State Menu, which made sense.

That all seems right to me.  Why was it moved?

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stalman wrote:

       Why did you change the position of the whole buffer "Erase
       Customization" button?  It forms a unit with the two Reset buttons and
       hence it is more logical to put them on the same line.  Also in the
       old order, the whole buffer buttons were in the same order as in the
       State Menu, which made sense.

   That all seems right to me.  Why was it moved?

If there are no objections, I will move the whole buffer
"Erase Customization" button back to its original place, which is the
same place it occupies in the State Menu.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

I do not know whether your changes are complete, but saving a themed
value to some other value and then doing "Erase Customization" still
resets to the no-themes default for the remainder of the current session.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

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

> I do not know whether your changes are complete, but saving a themed
> value to some other value and then doing "Erase Customization" still
> resets to the no-themes default for the remainder of the current session.

Should work now.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    That treats a symptom instead of the _real_ underlying bug.  I have
    already given one more example of a "surface bug" that is caused by
    the same underlying bug: if a setting is set by a theme, the "Erase
    Customization" item of the State Menu is enabled, whereas it should
    not be, because it is not going to have any effect (which is confusing
    to the user, because the State message says and keeps saying:
    "SAVED and set").

That seems right.

I see that Yidong just added a feature to make it display as "THEMED"
instead.  Does that fix this problem?

    What happens is that, since I just set column-number-mode to its
    standard-value, Custom thought that it just had to erase a line in my
    custom-set-variables form (that was not there).  Instead, Custom should
    have written a line in my custom-set-variables form explicitly setting
    column-number-mode to nil, to override my theme.

Indeed, that is a bug.  That part of Custom needs to check for
theme values.

      Obviously whenever Custom checks the value of
    standard-value, a bug is likely to result.

Yes, it seems like we need to check all of those places
and make sure they take account of themes.

Yidong, could you please do that?  Or was this done by the patch
you recently installed?

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

   if a setting is set by a theme, the "Erase Customization" item of
   the State Menu is enabled, whereas it should not be, because it is
   not going to have any effect (which is confusing to the user,
   because the State message says and keeps saying: "SAVED and set").

   That seems right.

   I see that Yidong just added a feature to make it display as "THEMED"
   instead.  Does that fix this problem?

It does fix this particular problem, provided that Chong grepped for
all places that check for the Custom state being standard.  They
should now normally check for standard or themed, because standard or
themed are essentially equivalent.  The main reason to distinguish
between them is to provide proper info to the user.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

	 Obviously whenever Custom checks the value of
       standard-value, a bug is likely to result.

   Yes, it seems like we need to check all of those places
   and make sure they take account of themes.

Also everybody writing future code for Custom should realize that when
they want to access the standard value, they should not just look at
the 'standard-value property but that they should use the non-user
theme value instead if there is one.  We should clearly document this
in cus-edit.el, if we want to continue to store the theme value in the
saved-value property.  If we stored it in the standard-value property,
that would not be necessary.

That is exactly what I find so unclean about the current Themes code.
People writing some general Custom code need to be continuously aware
of it.  If the Themes code were cleanly written, that would not be
necessary.  Conversely, fixing bugs in the Themes code can easily
produce bugs for people who never even use Themes.  If the Themes code
were cleanly written, that would not happen either.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    Also everybody writing future code for Custom should realize that when
    they want to access the standard value, they should not just look at
    the 'standard-value property but that they should use the non-user
    theme value instead if there is one.

Maybe we should add a subroutine which does this, to help people
get it right every time.

RE: Bug, probably related to Custom Themes.

[Drew Adams]

        Also everybody writing future code for Custom should
        realize that when they want to access the standard value,
        they should not just look at the 'standard-value property
        but that they should use the non-user
        theme value instead if there is one.

    Maybe we should add a subroutine which does this, to help people
    get it right every time.

1. Is there an acceptable alternative way to deal with this? I thought Luc
was saying that there was, but I could be mistaken (I haven't followed
everything in this thread).

One consequence of fixing the problem by providing such a subroutine will be
that code that tries to work with multiple versions of Emacs will become
more complex that it would otherwise be (some versions will have the
subroutine; others won't). I know that is not a priority concern of Emacs
development, but you might want to consider it at some (secondary) level.
"Users" of Emacs include not only its end users but also external-library
developers, and the latter sometimes try to provide code that works across
different Emacs versions, FBOFW.

2. Luc also seemed to be saying that there is unnecessary coupling now
between the themes code and the custom code, making writing code that uses
either of them trickier or more complex. If the two are as incestuously
intertwined as Luc suggests, wouldn't it make sense to cut some of the bonds
and have them shake hands at a more respectable distance? I don't know if
that would be possible before the release, but the impression I get from
Luc's description is that  maintenance and bug storms are looming in this
area.

I'm all for letting other libraries change custom values and states, as I've
stated previously. Custom is so important and potentially useful, that we
shouldn't confine its functionality to the Customize UI. But if other
libraries break Customize functionality, then that's not good. And if people
must be aware of multiple libraries and their effects in order to interact
with Customize (interactively or through code), then that's not good either.
My idea was to let other libraries use Customize functionality, but that
must be done cleanly and transparently - as if it were done by/in Customize
itself.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Drew Adams wrote:

   1. Is there an acceptable alternative way to deal with this? I thought Luc
   was saying that there was, but I could be mistaken (I haven't followed
   everything in this thread).

Yes there is, but one problem is that implementing it would probably
take some time and Richard absolutely wants to include Themes in the
release.  I already summarized the alternative earlier in this thread.
I could explain the details, but I believe that a decision has already
been made anyway, so it makes little sense.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    One consequence of fixing the problem by providing such a subroutine will be
    that code that tries to work with multiple versions of Emacs will become
    more complex that it would otherwise be (some versions will have the
    subroutine; others won't).

The code that calls this is in Emacs.  Lots of Emacs internals
change from version to version, and that's just life.

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

> Maybe we should add a subroutine which does this, to help people
> get it right every time.

This subroutine is basically what we need.

(defun custom-set-theme-variable (theme symbol value)
  "Record variable SYMBOL as being set by custom theme THEME, and set it to VALUE."
  (custom-push-theme 'theme-value symbol 'user 'set value)
  (funcall (or (get symbol 'custom-set) 'set-default)
           symbol (eval value)))

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    This subroutine is basically what we need.

    (defun custom-set-theme-variable (theme symbol value)
      "Record variable SYMBOL as being set by custom theme THEME, and set it to VALUE."
      (custom-push-theme 'theme-value symbol 'user 'set value)
      (funcall (or (get symbol 'custom-set) 'set-default)
	       symbol (eval value)))

I thought we were talking about a function to test whether SYMBOL's
value comes either from the default or a theme.  You've written a
subroutine to set a theme value.  Maybe that's useful too, but it
isn't the subroutine I was talking about.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

>From my earlier reply:

   If you save a "setting" (to use the brand new terminology) and then
   choose "Erase Customization" for the same setting, the no-themes
   default gets restored for the current session and for future sessions
   _until_ you choose "Erase Customization" for some _other_ setting.

Actually, it is a little bit more complex.  It appears to be: "for
some other setting _whose name comes later in the alphabet_".  Anyway,
the relevant fact is that the current behavior is essentially
unpredictable and makes no sense at all.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

The bug I described  occurs with a .emacs containing only the line:

(blink-cursor-mode 0)

Since I doubt that disabling cursor blinking has anything to do with
the bug, the bug can not be due to my customizations.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

You have to first toggle, then "Save for future Sessions" and then
"Erase Customization" to see the bug.  (Just check your .emacs, or
whatever your Custom file is called.)

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> In Emacs 21.3, Erase Customization doesn't write to .emacs either.

Come again?  It certainly does here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

This completely untested patch may do what you want.

*** emacs/lisp/cus-edit.el.~1.250.~	2005-12-21 16:18:52.000000000 -0500
--- emacs/lisp/cus-edit.el	2005-12-21 16:19:18.000000000 -0500
***************
*** 2745,2752 ****
        ;; save resets to standard when no theme set the value.
        (if (null (cdr (get symbol 'theme-value)))
  	  (put symbol 'theme-value nil))
!       (put symbol 'saved-variable-comment nil)
!       (custom-save-all))
      (widget-put widget :custom-state 'unknown)
      ;; This call will possibly make the comment invisible
      (custom-redraw widget)))
--- 2745,2751 ----
        ;; save resets to standard when no theme set the value.
        (if (null (cdr (get symbol 'theme-value)))
  	  (put symbol 'theme-value nil))
!       (put symbol 'saved-variable-comment nil))
      (widget-put widget :custom-state 'unknown)
      ;; This call will possibly make the comment invisible
      (custom-redraw widget)))
***************
*** 3406,3413 ****
        ;; Do not explictly save resets to standards without themes.
        (if (null (cdr (get symbol 'theme-face)))
  	  (put symbol  'theme-face nil))
!       (put symbol 'saved-face-comment nil)
!       (custom-save-all))
      (face-spec-set symbol value)
      (put symbol 'face-comment nil)
      (widget-value-set child value)
--- 3405,3411 ----
        ;; Do not explictly save resets to standards without themes.
        (if (null (cdr (get symbol 'theme-face)))
  	  (put symbol  'theme-face nil))
!       (put symbol 'saved-face-comment nil))
      (face-spec-set symbol value)
      (put symbol 'face-comment nil)
      (widget-value-set child value)

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Chong Yidong wrote:

   This completely untested patch may do what you want.

I do not believe so.  Your patches apparently remove the call to
custom-save-all, but custom-save-all needs to be called.

When I set `inhibit-splash-screen' to t, Custom writes:

 '(inhibit-splash-screen t)

in my custom-set-variables form.

When I then do "Erase Customization", custom-save-all should be called
to undo that and erase that line from the custom-set-variables form again.
It does that.  But then it also writes:

(custom-reset-variables
 '(inhibit-splash-screen nil))

into my Custom file.  It should not be doing that, for the reasons I
explained earlier.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

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

> When I set `inhibit-splash-screen' to t, Custom writes:
>
>  '(inhibit-splash-screen t)
>
> in my custom-set-variables form.
>
> When I then do "Erase Customization", custom-save-all should be called
> to undo that and erase that line from the custom-set-variables form again.
> It does that.  But then it also writes:
>
> (custom-reset-variables
>  '(inhibit-splash-screen nil))
>
> into my Custom file.

I think it should not write anything to .emacs.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Chong Yidong wrote:

   I think it should not write anything to .emacs.

It should get rid of the line:

 '(inhibit-splash-screen t)

in my custom-set-variables form or my Customization is not going to be
erased.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

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

> Chong Yidong wrote:
>
>    I think it should not write anything to .emacs.
>
> It should get rid of the line:
>
>  '(inhibit-splash-screen t)
>
> in my custom-set-variables form or my Customization is not going to be
> erased.

I think that Customize should only write to .emacs when the user
clicks on the "Save" button.  Maybe "Erase Customizations" should only
reset the values in the Customize buffer, but not make them take
effect.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Chong Yidong wrote:

   I think that Customize should only write to .emacs when the user
   clicks on the "Save" button.  Maybe "Erase Customizations" should only
   reset the values in the Customize buffer, but not make them take
   effect.

In the absence of themes, "Erase Customizations" should restore the
default value.  That is not in question.  It is what it has always
done and what it is documented to do.

If themes have been loaded, then, for reasons I explained in my
previous message, it should restore the theme value.  For reasons I
explained in my previous message, trying to restore the no-theme
default would lead to non-sensical behavior in one case or the other.
However, I have the impression that the current code does try to restore
the no-theme default, even if themes are loaded.  (Although it is not
correctly implemented.)  The result is a big nuisance, even for people
who use no themes whatsoever.

Apart from being the only way to avoid bugs, making "Erase Customization"
restore the theme value is the logical thing to do anyway.  Restoring
the no-theme default is likely to clash with the other settings.  If
somebody writes a theme for say, red-green colorblind people, then
deliberate deviations, well chosen by the user, might make sense, but
blindly restoring a general default color would likely produce
conflicts with the rest of the color design.  The same for other types
of themes.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    I think that Customize should only write to .emacs when the user
    clicks on the "Save" button.  Maybe "Erase Customizations" should only
    reset the values in the Customize buffer, but not make them take
    effect.

I am not sure in principle; anyway, now is not the time to consider
changing that.

However, the issue at hand seems to be a different one:
WHICH value it should install.  Isn't that so?

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

       I think that Customize should only write to .emacs when the user
       clicks on the "Save" button.  Maybe "Erase Customizations" should only
       reset the values in the Customize buffer, but not make them take
       effect.

   I am not sure in principle; anyway, now is not the time to consider
   changing that.

"Reset to Current" does exactly what Chong apparently would want
"Erase Customization" to do.  I personally believe that the old tag
("Reset to Default") was less confusing than "Erase Customization"
and made the relation with the other reset operations more clear.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

				  I personally believe that the old tag
    ("Reset to Default") was less confusing than "Erase Customization"
    and made the relation with the other reset operations more clear.

"Reset" sounds like a counterpart to "set", and thus
changing only the current values, not the saved values.
I think "Erase Customizations" is clearer, because it says that
the commnd gets rid of your existing customizations.

Re: Bug, probably related to Custom Themes.

[Alfred M. Szmidt]

				     I personally believe that the old tag
       ("Reset to Default") was less confusing than "Erase Customization"
       and made the relation with the other reset operations more clear.

   "Reset" sounds like a counterpart to "set", and thus
   changing only the current values, not the saved values.
   I think "Erase Customizations" is clearer, because it says that
   the commnd gets rid of your existing customizations.

I also think that `Erase Customization' is a bit confusing, but `Reset
Customization' is equally confusing I think. How about `Revert
Customization' which says that the existing values get removed, and
reverted to whatever was the setting when they weren't set?

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    "Reset" sounds like a counterpart to "set", and thus
>    changing only the current values, not the saved values.
>    I think "Erase Customizations" is clearer, because it says that
>    the commnd gets rid of your existing customizations.
>
> I also think that `Erase Customization' is a bit confusing, but `Reset
> Customization' is equally confusing I think. How about `Revert
> Customization' which says that the existing values get removed, and
> reverted to whatever was the setting when they weren't set?

Why not "Revert to Defaults"?  That seems to be the canonical phrase.

My personal opinion is that the "Set for Current Session" and "Reset
to Current" buttons are superfluous.  Most other programs don't
provide a separate "set but don't save" command, and it's
unneccessary.  It took me a while to realize what all those Customize
buttons were supposed to do, and it would probably be worse for
newbies.

If we eliminate "Set for Current Session" and "Reset to Current", the
interface would be much cleaner:

 [Cancel Changes] [Save Changes]
 [Reset to Defaults]    [Finish]

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

   My personal opinion is that the "Set for Current Session" and "Reset
   to Current" buttons are superfluous.

"Set for Current Session" is so you will not have to remember to set
it back before you exit Emacs, nor to which value you wanted to set it
back to (remember that some values you set through Custom can be long
and complex).

"Reset to Current" is so that if you mess up a long and complex value
by editing it, you can safely discard your edits.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

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

>    My personal opinion is that the "Set for Current Session" and "Reset
>    to Current" buttons are superfluous.
>
> "Set for Current Session" is so you will not have to remember to set
> it back before you exit Emacs, nor to which value you wanted to set it
> back to (remember that some values you set through Custom can be long
> and complex).
>
> "Reset to Current" is so that if you mess up a long and complex value
> by editing it, you can safely discard your edits.

I know what those buttons do.  My point is that they're not very
useful, while making it harder to figure out how to use the Customize
buffer.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    If we eliminate "Set for Current Session" and "Reset to Current", the
    interface would be much cleaner:

     [Cancel Changes] [Save Changes]
     [Reset to Defaults]    [Finish]

I recall there was a discussion of a similar proposal,
a year or two ago.  There were people for it and against it.
I don't remember the details, but it didn't convince me.

Re: Bug, probably related to Custom Themes.

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> If we eliminate "Set for Current Session" and "Reset to Current", the
> interface would be much cleaner:
>
>  [Cancel Changes] [Save Changes]
>  [Reset to Defaults]    [Finish]

This is a nice simplification, and the two other items are still
available on the [State] button when needed for individual options.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    How about `Revert
    Customization' which says that the existing values get removed, and
    reverted to whatever was the setting when they weren't set?

That would be confusing because is not analogous to `revert-buffer'.
I don't like the idea.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

       How about `Revert
       Customization' which says that the existing values get removed, and
       reverted to whatever was the setting when they weren't set?

   That would be confusing because is not analogous to `revert-buffer'.
   I don't like the idea.

Maybe we could change "Reset to Current" to "Discard Edits", as
somebody suggested at one point ("Reset to current" is not going to
reset any setting, only text in the Custom buffer.)  That would make
"Erase Customization" look less like it was going to erase your editing.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    Maybe we could change "Reset to Current" to "Discard Edits", as
    somebody suggested at one point ("Reset to current" is not going to
    reset any setting, only text in the Custom buffer.)

How about "Show Current Settings" or "Show Current Values"?
And "Reset to Saved" could be "Show Saved Settings" or
"Show Saved Values"?

      That would make
    "Erase Customization" look less like it was going to erase your editing.

It does erase your editing, as well as erasing saved values.

What about "Cancel Customization", "Cancel Saved Settings",
"Erase Saved Settings", etc?

Re: Bug, probably related to Custom Themes.

[Chong Yidong]

>     Maybe we could change "Reset to Current" to "Discard Edits", as
>     somebody suggested at one point ("Reset to current" is not going to
>     reset any setting, only text in the Custom buffer.)
>
> How about "Show Current Settings" or "Show Current Values"?
> And "Reset to Saved" could be "Show Saved Settings" or
> "Show Saved Values"?

This is a good idea.

>       That would make
>     "Erase Customization" look less like it was going to erase your editing.
>
> It does erase your editing, as well as erasing saved values.
>
> What about "Cancel Customization", "Cancel Saved Settings",
> "Erase Saved Settings", etc?

Maybe we should replace this with "Show Standard Values", which would
not erase saved values; the user would use "Save for Future Sessions"
to apply the changes, as with the other "Show" buttons.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

       Maybe we could change "Reset to Current" to "Discard Edits", as
       somebody suggested at one point ("Reset to current" is not going to
       reset any setting, only text in the Custom buffer.)

   How about "Show Current Settings" or "Show Current Values"?

It is longer than the current text and, to me, not clearer at all.
Actually, it would be confusing, certainly for the whole buffer
button.  It makes it appear that you have to press this button to see
the current values and makes you wonder what the shown values are
(defaults, saved values?).  For the State button message, the plural
is wrong.

What is wrong with "Discard Edits" or "Undo Edits" or "Revert Edits",
since that is exactly what it does?  Otherwise, we could just keep
"Reset to Current".

   And "Reset to Saved" could be "Show Saved Settings" or
   "Show Saved Values"?

"Reset to Saved" does exactly what it says: it resets to the saved
value.  It does not just show the saved value.

	 That would make
       "Erase Customization" look less like it was going to erase your editing.

   It does erase your editing, as well as erasing saved values.

   What about "Cancel Customization", "Cancel Saved Settings",
   "Erase Saved Settings", etc?

The last two would be misleading: it is not just going to cancel and
erase saved values, but edited, set and rogue values as well.  "Cancel
Customization" would be better, but might be confusing because
"Cancel" is used in the sense of "Undo Edits" by some other
customization interfaces.

Actually, "Erase Customization" is not that bad.  I just thought
changing "Reset to Current" to "Discard Edits" would make it still
more clear that the edits in the buffer are just edits, not
customizations, thereby eliminating any confusion for
"Erase Customization" as well.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Lennart Borgman]

Luc Teirlinck wrote:

>Richard Stallman wrote:
>
>       Maybe we could change "Reset to Current" to "Discard Edits", as
>       somebody suggested at one point ("Reset to current" is not going to
>       reset any setting, only text in the Custom buffer.)
>
>   How about "Show Current Settings" or "Show Current Values"?
>
>It is longer than the current text and, to me, not clearer at all.
>Actually, it would be confusing, certainly for the whole buffer
>button.  It makes it appear that you have to press this button to see
>the current values and makes you wonder what the shown values are
>(defaults, saved values?).  For the State button message, the plural
>is wrong.
>  
>
Perhaps it would be more clear if the button corresponding to the values 
that is shown were disabled and dimmed? Or maybe replaced with a text 
like "Showing Current  Values"?

But as Luc point out this would require changing the logic too.

>"Reset to Saved" does exactly what it says: it resets to the saved
>value.  It does not just show the saved value.
>...
>Actually, "Erase Customization" is not that bad.  I just thought
>changing "Reset to Current" to "Discard Edits" would make it still
>more clear that the edits in the buffer are just edits, not
>customizations, thereby eliminating any confusion for
>"Erase Customization" as well.
>  
>
I like Erase Customization too.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

       How about "Show Current Settings" or "Show Current Values"?

    It is longer than the current text and, to me, not clearer at all.
    Actually, it would be confusing, certainly for the whole buffer
    button.  It makes it appear that you have to press this button to see
    the current values

No, the words don't mean that, and I see no reason to think people
are particularly likely to misunderstand them in that way.

    and makes you wonder what the shown values are
    (defaults, saved values?).

That is good!  The values shown in the buffer are NOT
in general the current values.

      For the State button message, the plural
    is wrong.

That is not a big deal.  Anyway, we could use the singular for those
buttons.


       What about "Cancel Customization", "Cancel Saved Settings",
       "Erase Saved Settings", etc?

    The last two would be misleading: it is not just going to cancel and
    erase saved values, but edited, set and rogue values as well.

That is not a problem.  It is fine if the name of an operation
describes only the most important thing it does.  The name need not
describe all the lesser things the operation also does.

       And "Reset to Saved" could be "Show Saved Settings" or
       "Show Saved Values"?

    "Reset to Saved" does exactly what it says: it resets to the saved
    value.  It does not just show the saved value.

I had forgotten.  If this button actually sets the value,
then "reset" is a good name for it.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

       and makes you wonder what the shown values are
       (defaults, saved values?).

   That is good!  The values shown in the buffer are NOT
   in general the current values.

They are the current value _unless_ you edited the value.  They can
sometimes be the saved or standard value in addition to being the current
value, but they are shown _because_ they are the current value.  If
you change the current value, the shown value changes to the new
current value.

Anyway, the main thing the button does is to get rid of your edits.
It does not just temporarily show the current value, before you go
back to your edits.

The reason to press the "Reset to Current" button is to discard (or
revert or undo) your edits, so you do not accidentally set or save them.
The fact that it also again shows the current set value is a side effect.
That is why I proposed to rename "Reset to Current" to "Revert Edits"
or similar.  But the current "Reset to Current" is acceptable and
better than something which only emphasizes a side effect.

	  What about "Cancel Customization", "Cancel Saved Settings",
	  "Erase Saved Settings", etc?

       The last two would be misleading: it is not just going to cancel and
       erase saved values, but edited, set and rogue values as well.

   That is not a problem.  It is fine if the name of an operation
   describes only the most important thing it does.  The name need not
   describe all the lesser things the operation also does.

The most important thing it is going to do depends on whether the
value you apply it to is saved, set or edited.  Why use a misleading
two word term (Saved Settings) while you have a clear one word term
(Customization)?

Sincerely,

Luc.

Reset buttons in Customize (Was: Bug, probably related to Custom Themes.)

[Chong Yidong]

I did a little more thinking about the Customize interface.  The
question of which button does what is rather poorly thought out.  As
evidence of this, the "Reset to Saved" buttons apparently managed to
confuse both Richard and myself.

Richard put in the y-or-n-p message "Update buffer text to show all
saved settings?".  The mistake is that "Reset to current" also sets
the *current* values of the customize items to their *saved* values,
even if they are different.

But this is an easy mistake to make, because it's not clear that
"Reset to Saved" would have this effect -- unless you try it out.

I've fixed that message, but I think it is better to root out the
confusion.  I suggest changing custom-reset-current and
custom-reset-saved to *really* become "Show Current Value" and "Show
Saved Value" (and custom-reset-standard to "Show Standard Value").
That is, the buttons only change the values shown in the widgets,
without setting them.  The user explicitly calls "Set for Current
Session" or "Save for Future Sessions" to do what he wants, which
reduces the risk of confusion.

However, an even better simplification is what I previously suggested:
do away with the concept of "set for current session", and make
Customize save automatically.  This eliminates the above confusion
entirely, because the current value is always the saved value, as long
as you stick to Customize.  (And even external changes would be easy
to handle.)

To see how non-standard the "set for current session" concept is, run
Firefox go to Edit->Preferences.  Do you see any "set for current
session only" button?  There isn't one -- nor in the Gnome control
center, or the preferences of every other program around.

Customize is supposed to be something that ordinary users can use.

Re: Reset buttons in Customize (Was: Bug, probably related to Custom Themes.)

[Giorgos Keramidas]

On 2006-01-04 12:58, Chong Yidong <cyd@stupidchicken.com> wrote:
> However, an even better simplification is what I previously suggested:
> do away with the concept of "set for current session", and make
> Customize save automatically.  This eliminates the above confusion
> entirely, because the current value is always the saved value, as long
> as you stick to Customize.  (And even external changes would be easy
> to handle.)

I regularly use "set for current session" to test changes that affect
the way things work, but revert to my saved settings a while later.
Being able to experiment with several customizations at once, without
fearing that I will ruin my ~/.emacs file is, in my opinion, something
that for me works as a motivation to experiment with new customizations.

I'd be sad to see this go away, but this is perhaps just me.

Re: Reset buttons in Customize

[David Kastrup]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On 2006-01-04 12:58, Chong Yidong <cyd@stupidchicken.com> wrote:
>> However, an even better simplification is what I previously suggested:
>> do away with the concept of "set for current session", and make
>> Customize save automatically.  This eliminates the above confusion
>> entirely, because the current value is always the saved value, as long
>> as you stick to Customize.  (And even external changes would be easy
>> to handle.)
>
> I regularly use "set for current session" to test changes that affect
> the way things work, but revert to my saved settings a while later.
> Being able to experiment with several customizations at once, without
> fearing that I will ruin my ~/.emacs file is, in my opinion, something
> that for me works as a motivation to experiment with new customizations.
>
> I'd be sad to see this go away, but this is perhaps just me.

No.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reset buttons in Customize (Was: Bug, probably related to Custom Themes.)

[Luc Teirlinck]

Chong Yidong wrote:

   But this is an easy mistake to make, because it's not clear that
   "Reset to Saved" would have this effect -- unless you try it out.

Why does it surprise you that a button that says "Reset to Saved"
actually resets to saved?

   I suggest changing custom-reset-current and
   custom-reset-saved to *really* become "Show Current Value" and "Show
   Saved Value" (and custom-reset-2standard to "Show Standard Value").
   That is, the buttons only change the values shown in the widgets,
   without setting them.  The user explicitly calls "Set for Current
   Session" or "Save for Future Sessions" to do what he wants, which
   reduces the risk of confusion.

That would mean two new whole buffer buttons and two new items in the
State menu.

   However, an even better simplification is what I previously suggested:
   do away with the concept of "set for current session", and make
   Customize save automatically.

I believe that many Custom users often use these buttons.  I certainly
do.

I believe that the changes you suggest are a bad idea.  It is
_certainly_ a very bad idea to suggest these radical changes to
Custom supposedly "shortly" before a release.

Sincerely,

Luc.

Re: Reset buttons in Customize

[Chong Yidong]

> Why does it surprise you that a button that says "Reset to Saved"
> actually resets to saved?

Read my post again.  The question is whether "Reset" means to make the
saved value take effect in the Emacs session, or only display it in
the Customize buffer widgets without affecting the current value.  It
is not a priori clear which meaning it has (in fact, my first guess
would be the latter).

>    I suggest changing custom-reset-current and
>    custom-reset-saved to *really* become "Show Current Value" and "Show
>    Saved Value" (and custom-reset-2standard to "Show Standard Value").
>    That is, the buttons only change the values shown in the widgets,
>    without setting them.  The user explicitly calls "Set for Current
>    Session" or "Save for Future Sessions" to do what he wants, which
>    reduces the risk of confusion.
>
> That would mean two new whole buffer buttons and two new items in the
> State menu.

Nope -- the point is to *replace* the "reset to *" buttons, so there
will be no change in the number of buttons.

>    However, an even better simplification is what I previously suggested:
>    do away with the concept of "set for current session", and make
>    Customize save automatically.
>
> I believe that many Custom users often use these buttons.  I certainly
> do.

It's hard to judge this, especially if you want to take into account
the number of users who don't use Customize because it is too
confusing.  Even in the worst case scenario, you can reset to the
standard value and start again.

> I believe that the changes you suggest are a bad idea.  It is
> _certainly_ a very bad idea to suggest these radical changes to
> Custom supposedly "shortly" before a release.

These do not entail very large changes to Custom internals.  Anyway,
other issues are holding the release.

Re: Reset buttons in Customize

[Lennart Borgman]

Chong Yidong wrote:

>>   I suggest changing custom-reset-current and
>>   custom-reset-saved to *really* become "Show Current Value" and "Show
>>   Saved Value" (and custom-reset-2standard to "Show Standard Value").
>>   That is, the buttons only change the values shown in the widgets,
>>   without setting them.  The user explicitly calls "Set for Current
>>   Session" or "Save for Future Sessions" to do what he wants, which
>>   reduces the risk of confusion.
>>
>>That would mean two new whole buffer buttons and two new items in the
>>State menu.
>>    
>>
>
>Nope -- the point is to *replace* the "reset to *" buttons, so there
>will be no change in the number of buttons.
>  
>
I like the idea. The buttons could also be grouped according to whether 
they applies to field values or setting/saving.

If this is not a big change then it would IMO be good to do it now, 
since it is now that Custom really is supposed to be used. Care must be 
taken for the strange "hidden" values of course.

>  
>
>>   However, an even better simplification is what I previously suggested:
>>   do away with the concept of "set for current session", and make
>>   Customize save automatically.
>>
>>I believe that many Custom users often use these buttons.  I certainly
>>do.
>>    
>>
I too use "set for current session".

Re: Reset buttons in Customize

[Luc Teirlinck]

Chong Yidong wrote:

   Nope -- the point is to *replace* the "reset to *" buttons, so there
   will be no change in the number of buttons.

How would the user make the values take effect for the current session
and/or for future sessions then.  You said:

   The user explicitly calls "Set for Current Session" or "Save for
   Future Sessions" to do what he wants, which reduces the risk of
   confusion.

What does "explicitly call" mean?  That means two new buttons and two
new items in the State menu.  Unless you mean to call the whole buffer
_functions_.  These functions operate (in an often very confusing way)
on the whole buffer and are not suitable for use with the State button.

   > I believe that many Custom users often use these buttons.  I certainly
   > do.

   It's hard to judge this, especially if you want to take into account
   the number of users who don't use Customize because it is too
   confusing.  Even in the worst case scenario, you can reset to the
   standard value and start again.

Sometimes the saved value can be very complex and hard to remember.
It might be, for instance, a regexp somebody else wrote for you.

Sincerely,

Luc.

Re: Reset buttons in Customize

[Chong Yidong]

>    Nope -- the point is to *replace* the "reset to *" buttons, so there
>    will be no change in the number of buttons.
>
> How would the user make the values take effect for the current session
> and/or for future sessions then.

By clicking on the "Set for current session" and "Save for future
sessions" buttons.  Simple, no?

Re: Reset buttons in Customize

[Luc Teirlinck]

Chong Yidong wrote:

   By clicking on the "Set for current session" and "Save for future
   sessions" buttons.  Simple, no?

Will not work for "Show Standard Value".  Saving will fix that value
in the user's .emacs, overriding later changes to the default and
overriding theme values.  That _may_ be what the user wants.  But he
might also just want to get rid of his customization, by having no
line whatsoever in his .emacs for that option, thereby seeing later
changes to the default and theme values.  Seeing later changes to the
default is especially important for hooks, property lists and
association list, which Custom currently can not really handle
properly (because it uses setq, whereas these options should really be
customized using add-hook and similar).

So you would need at least one extra button.

Sincerely,

Luc.

Re: Reset buttons in Customize

[Chong Yidong]

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

> Chong Yidong wrote:
>
>    By clicking on the "Set for current session" and "Save for future
>    sessions" buttons.  Simple, no?
>
> Will not work for "Show Standard Value".  Saving will fix that value
> in the user's .emacs, overriding later changes to the default and
> overriding theme values.  That _may_ be what the user wants.  But he
> might also just want to get rid of his customization, by having no
> line whatsoever in his .emacs for that option, thereby seeing later
> changes to the default and theme values.

That one is easy -- if value is the same as the standard value, do
what you just said, and don't leave the line in .emacs.

If that makes you unhappy, then we can let Erase Customization do the
same thing it does now.  (Not that there's currently no way to show
the standard value of a widget without applying it.)  No biggie.

> So you would need at least one extra button.

Nope.

Re: Reset buttons in Customize

[Luc Teirlinck]

Chong Yidong wrote:

   That one is easy -- if value is the same as the standard value, do
   what you just said, and don't leave the line in .emacs.

The user may _want_ to override themes (or even future changes to the
default).

Sincerely,

Luc.

Re: Reset buttons in Customize

[Chong Yidong]

>    That one is easy -- if value is the same as the standard value, do
>    what you just said, and don't leave the line in .emacs.
>
> The user may _want_ to override themes

That is easy to detect.

> (or even future changes to the default).

Be serious.

Re: Reset buttons in Customize

[Luc Teirlinck]

Chong Yidong wrote:

   > The user may _want_ to override themes

   That is easy to detect.

How?

   > (or even future changes to the default).

   Be serious.

I was thinking of CVS users, who might be tired of some default
getting changed repeatedly.

Sincerely,

Luc.

Re: Reset buttons in Customize

[Luc Teirlinck]

Chong Yidong wrote:

   > I believe that the changes you suggest are a bad idea.  It is
   > _certainly_ a very bad idea to suggest these radical changes to
   > Custom supposedly "shortly" before a release.

   These do not entail very large changes to Custom internals.

This once more shows how very disruptive apparently small changes can be.
Your proposed changes would disrupt Custom's design by using evaluated
values where unevaluated Lisp expressions should be used.  This would
have caused a variety of bugs.

As I already explained, most of what you want is _already_ in Custom,
but without the bugs.

Sincerely,

Luc.

Re: Reset buttons in Customize (Was: Bug, probably related to Custom Themes.)

[Luc Teirlinck]

First you changed the place of the "Erase Customization" button
*without asking for any input*.  Then I explained you why that was a bad
idea and Richard agreed with me.  Then I asked whether there were any
objections to reverting that change.  There were none.  You asked me
to wait until you committed a series of changes.  I waited until you
installed those changes, then I moved the button back to its original
position.

Now you changed the buttons completely around again, again in a way
that makes no sense whatsoever, once more *without asking for any
input*.  You changed the order of the state button, for inexplicable
reasons, putting the least important items on top and the most
important at the bottom (again without asking for input).  Why did you
do this?  The previous order made sense and you replaced it by the
worst order possible.

I do not understand what the new "Show value widget" in the State Menu
is supposed to do.

These changes, especially the ones to the State buttons, make using
Custom more difficult and less convenient.  I believe that it is very
important to revert them.

In the future, could you please ask for input from people who
actually use Custom before making radical changes to it?  Could you
please also refrain from engaging in commit wars?

Sincerely,

Luc.

Re: Reset buttons in Customize

[Chong Yidong]

> First you changed the place of the "Erase Customization" button
> *without asking for any input*.  Then I explained you why that was a bad
> idea and Richard agreed with me.  Then I asked whether there were any
> objections to reverting that change.  There were none.  You asked me
> to wait until you committed a series of changes.  I waited until you
> installed those changes, then I moved the button back to its original
> position.
>
> Now you changed the buttons completely around again, again in a way
> that makes no sense whatsoever, once more *without asking for any
> input*.

If I'm honest, it was to annoy you.  It's now back in the old order ;-)

Re: Reset buttons in Customize

[Luc Teirlinck]

Chong Yidong wrote:

   If I'm honest, it was to annoy you.  It's now back in the old order ;-)

But there are still problems, which are regressions.

You changed "Reset to current" to "Reset to current value" and "Reset
to saved" to "Reset to saved value".  This just increases the
confusion you complained about.

Compared to "Reset to current", "Reset to current value" _increases_
the impression that some value is going to be changed, whereas all
that happens is that the user's edits are reverted.

I believe that any confusion is caused by the misleading symmetry with
"Reset to current" and "Reset to Saved" (which your changes enhanced
rather than corrected).  That is exactly why I proposed to rename
"Reset to Current" to "Revert Edits" or similar.

You changed "Use backup value" to "Reset to backup value".  This
implies that some change is going to be completely reverted, like the
other Reset operations do.  This is not the case.  If the saved value
is 1 and you change the saved value to 2, then "Reset to backup value" is
going to reset the current value to 1, but the saved value is still 2.
So if this is going to be something different from "Use backup value",
it should be "Set to backup value".  The "Re" in "Reset" is confusing.
That it partially reverts to a previous value is already implicit in
"backup".

"Show value widget" is completely cryptic.  It took me a long time to
figure out that this was what was originally called "Do not show as
Lisp expression".

You changed "Show initial Lisp expression" to "Show Lisp expression".
This suggest that the _current_ value will be shown as Lisp expression.
Actually the saved (or standard) value gets shown as a Lisp
expression.  (Hence the "initial", which you erased).  Maybe "saved"
would be clearer than "initial".

Changing the latter two to what they were would be a big improvement
over your changes, but maybe it might be better to change "Do not show
as Lisp expression" to "Show current value" (which is exactly what it
does): it shows the _current_ value, rather than the saved (or
standard), and it shows the current _value_, rather than expression.

Summary:

After your changes      Before your changes    Suggested alternatives
-------------------     -------------------    ----------------------

Reset to current value  Reset to current       Discard Edits
                                               Undo Edits
                                               Revert Edits

Reset to backup value   Use backup value       Set to backup value

Show value widget   Don't show as Lisp expression  Show current value

Show Lisp expression  Show initial Lisp expression  
                                               Show saved Lisp expression


Sincerely,

Luc.

RE: Reset buttons in Customize (Was: Bug, probably related to Custom Themes.)

[Drew Adams]

    However, an even better simplification is what I previously suggested:
    do away with the concept of "set for current session", and make
    Customize save automatically.

No, please don't do that. I just scanned your message, so forgive me if I
missed something, but I definitely don't like this part.

It is very useful to use Customize to, say, change a face and try it for a
while, without needing to remember what the previously saved value was in
order get back to the original setting. Especially if you make multiple
Customize changes, keeping track of all such changes manually and reversing
them would be a pain.

This is one of the *advantages* of Emacs's treatment of
preferences/settings/options over the treatment in other apps.

I agree that the Customize GUI needs reworking, but 1) not before the
release and 2) getting rid of being able to make non-persistent changes is
*not* a change we should make.

Re: Reset buttons in Customize (Was: Bug, probably related to Custom Themes.)

[Richard M. Stallman]

We will not eliminate "set for current session".  That is my decision.

I will try to read tomorrow the thread about the Custom changes that
were made today.

Re: Reset buttons in Customize (Was: Bug, probably related to Custom Themes.)

[Luc Teirlinck]

Chong Yidong wrote:

   I suggest changing custom-reset-current and
   custom-reset-saved to *really* become "Show Current Value" and "Show
   Saved Value" (and custom-reset-standard to "Show Standard Value").

For the Saved and Standard values, those would have the problem of
showing and saving evaluated values where often Lisp expressions should
be saved.  This could lead to serious bugs.  Please read the
introductory comment in cus-edit.el.

"Show initial Lisp expression" (in which you deleted "initial")
_already_ does what your "Show saved Value" does (but in a way that
avoids the bugs inherent in your suggestion).  If the user saved
something as a Lisp expression, then that is likely what he needs
to edit, not the evaluated value.

"Don't show as Lisp expression" (which you changed to "Show value
widget") already does what your "Show Current Value" does.  It shows
the current value if the saved value was shown as a Lisp expression.
On the other hand "Reset to Current" does _not_ necessarily show the
current value, what it does is revert user edits.  I gave the details
in a previous message.

Sincerely,

Luc.

Re: Reset buttons in Customize

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> However, an even better simplification is what I previously
> suggested: do away with the concept of "set for current session",
> and make Customize save automatically.  This eliminates the above
> confusion entirely, because the current value is always the saved
> value, as long as you stick to Customize.  (And even external
> changes would be easy to handle.)
>
> To see how non-standard the "set for current session" concept is,
> run Firefox go to Edit->Preferences.  Do you see any "set for
> current session only" button?  There isn't one -- nor in the Gnome
> control center, or the preferences of every other program around.

Which is a nuisance.

> Customize is supposed to be something that ordinary users can use.

Well, one possibility would be to have a toggle "Make Changes persist"
that defaults to on, except when the actual value and the saved value
differ.  There would be no explicit button to set or save changes.
Something like that.

However, I think that this topic is taking more attention than it
would warrant at this point of time.  We should just get something
reasonable done and move on.  After the release, it might make sense
for one or two volunteers to discuss and implement a consistent and
working Customize interface.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reset buttons in Customize (Was: Bug, probably related to Custom Themes.)

[Richard M. Stallman]

    Richard put in the y-or-n-p message "Update buffer text to show all
    saved settings?".  The mistake is that "Reset to current" also sets
    the *current* values of the customize items to their *saved* values,
    even if they are different.

Yes, now I remember.  In our previous discussion, we decided that
these commands should not skip levels--so, for instance, a command
operating on the levels of buffer text and saved values should not
jump over the level of current settings.

I had forgotten about this, and did not see anything that clued me in.
The names did not indicate it clearly.

However, that doesn't mean it is better to change this decision.

    I've fixed that message, but I think it is better to root out the
    confusion.

It was good to fix the message, and I agree we should do something to
clarify the situation, but that doesn't mean we should change the
semantics.

    I suggest changing custom-reset-current and
    custom-reset-saved to *really* become "Show Current Value" and "Show
    Saved Value" (and custom-reset-standard to "Show Standard Value").
    That is, the buttons only change the values shown in the widgets,
    without setting them.  The user explicitly calls "Set for Current
    Session" or "Save for Future Sessions" to do what he wants, which
    reduces the risk of confusion.

This is extremely clear--for a programmer.  In our previous
discussion, we concluded that this would not be clear for
non-programmers who are starting to use Emacs.  That's why we
implemented the decision which I temporarily didn't remember.


As for simplifying the complexity the complexity caused
by having current values and saved values, perhaps that would
be easier to understand as "temporary values".  However,
now is not the time to consider such a change.

Re: Reset buttons in Customize

[Bill Wohler]

I think Chong's idea about making all changes persist is a great one.
It's something that I've thought about. It will simplify the interface
a LOT since most of the buttons would go away. That said, I use Set
for Current Session a LOT (as do most of you) so we'll have to do
something about that. After the release.

For now, a couple of name tweaks, without changing the semantics as
Richard suggests is wise.

I've never like Erase Customization. How about just Default?

The Reset to Current has always baffled me. I *think* it means to
change the settings to what they were before Customize was entered,
but I'm not sure. I had thought of Undo; this was validated by Luc's
message. It's not a Revert; that command is better suited for
reverting from the saved setting in .emacs.

We can make the buttons at the top one line with probably more
clarity:

  Set Save Undo Revert Default Finish

Ditto for the menu items. What the heck is Reset to Backup and Show
Value Widget?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Reset buttons in Customize

[Luc Teirlinck]

Bill Wohler wrote:

   The Reset to Current has always baffled me. I *think* it means to
   change the settings to what they were before Customize was entered,
   but I'm not sure.

and:

   Ditto for the menu items. What the heck is Reset to Backup and Show
   Value Widget?

The current (recently changed) names for the State Menu items are very
misleading.  Several have very little to do with what the menu item
really does.  Here is a summary of what the items you mention do, with
my suggested more accurate names (which I already suggested earlier).

Custom can show two things that you can edit to install a new value
for a setting:

The current (evaluated) value of the setting and the saved (or
standard, if there is no saved)  _unevaluated_ Lisp expression.

You switch between the two using the State menu items whose labels
were very recently changed to "Show Lisp expression" (which shows the
latter) and "Show value widget" (which shows the former).  As I
already pointed out, "Show Lisp expression" is misleading, since it
suggests that the _current_ value will be shown as a Lisp expression,
which is false.  It should be "Show saved Lisp expression".  It is
actually saved or standard if there is no saved, but that would be
quite long and standard seems the _obvious_ alternative if there is no
saved.  "Show value widget" is cryptic.  Why not: "Show current value",
which says exactly what it does.  Note that it is only enabled if the
saved Lisp expression (as opposed to the current value) is shown.

"Reset to current value" is misleading.  That button resets the text
in the value field to _whatever_ it was before you started editing it
(current value _or_ unevaluated saved Lisp expression) and does not set
any value.  It undoes your edits.  That is exactly what it does.  Why
not say what it does: "Undo edits".

"Reset to backup value" does not really reset anything.  It sets the
current value to some backup value.  It does not change the saved
value.  I would call this: "Set to backup".  It would take too long to
explain in the menu item how the backup value is chosen, but it rather
consistently turns out to be what you would expect.  _After the release_,
it might be better to replace this menu item with a history feature
that would only affect the value shown in the buffer and would not
automatically set anything.  The current feature is very useful and
necessary to avoid accidentally loosing complex values.  So it can not
just be discarded.  But I believe that a minibuffer history style
feature would be even more useful.

Summary of proposed changes (assuming we adopt your capitalization
suggestion, on which I have no strong opinion either way):

Reset to current value  Undo Edits

Reset to backup value   Set to Backup Value

Show value widget       Show Current Value

Show Lisp expression    Show Saved Lisp Expression

Sincerely,

Luc.

Re: Reset buttons in Customize

[Luc Teirlinck]

Bill Wohler wrote:

   I've never like Erase Customization.

After some more thinking, "Erase Customization" is indeed confusing,
as in several places in the Customize docs, the word "customized
value" is used in the sense of "set but not saved".  For instance:

  `M-x customize-customized'
       Set up a customization buffer containing all settings that you have
       customized but not saved.

I now propose the following State Menu:

Set for Current Session
Save for Future Sessions
Undo Edits
Revert to Saved
Revert to Standard
Set to Backup value
--------------------------
Add Comment
--------------------------
Show Current Value
Show Saved Lisp Expression


I believe that the use of "Revert" instead of the original "Reset"
takes care of Richard's objections to the original "Reset to Standard".

Note that the "Undo Edits" item is only active when there are edits,
in which case the individual setting State message says:

  EDITED, shown value does not take effect until you set or save it.

and the whole buffer State message says:

  something in this group has been edited but not set.

so that the "Edits" in "Undo Edits" is unambiguous.

Sincerely,

Luc.

Re: Reset buttons in Customize

[Bill Wohler]

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

> I believe that the use of "Revert" instead of the original "Reset"
> takes care of Richard's objections to the original "Reset to Standard".

I like your suggestions. The latter could be just "Default."

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Reset buttons in Customize

[Luc Teirlinck]

Bill Wohler wrote:

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

   > I believe that the use of "Revert" instead of the original "Reset"
   > takes care of Richard's objections to the original "Reset to Standard".

   I like your suggestions. The latter could be just "Default."

In Emacs, "Default value" is often used as the opposite of
"buffer local value".  "Standard" is unambiguous and is what is
usually used to denote the value as given in the defcustom.  It is
also the term that the State message uses.

Sincerely,

Luc.

Re: Reset buttons in Customize

[David Kastrup]

Bill Wohler <wohler@newt.com> writes:

> Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
>
>> I believe that the use of "Revert" instead of the original "Reset"
>> takes care of Richard's objections to the original "Reset to
>> Standard".
>
> I like your suggestions. The latter could be just "Default."

We need some sort of authentication/hashing mechanism that makes sure
one can't post to a thread before having read it through completely.

This is just running in circles.  If it was my decision, I'd just tell
Luc to do what he considers right since he is obviously the one who
has both an interest in that and invested a load of thought of it, not
least of all because he still is replying to messages like these.

We have spent far too much time on this topic by now.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reset buttons in Customize

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

>   If it was my decision, I'd just tell
> Luc to do what he considers right since he is obviously the one who
> has both an interest in that and invested a load of thought of it

I'd second that!

(and besides, I think Luc's last proposal is very good!)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Reset buttons in Customize

[Luc Teirlinck]

>From my earlier message:

   I now propose the following State Menu:

and, of course, similar changes to the whole buffer buttons, to keep
the names identical to those in the State menu.

Sincerely,

Luc.

Re: Reset buttons in Customize

[Richard M. Stallman]

    After some more thinking, "Erase Customization" is indeed confusing,
    as in several places in the Customize docs, the word "customized
    value" is used in the sense of "set but not saved".  For instance:

I am not conviced this is really confusing, but if it is, I would
rather change the documentation, and maybe the name of
`customize-customized'.

    Set for Current Session
    Save for Future Sessions
    Undo Edits

Undo Edits seems clear at least.

    Revert to Saved
    Revert to Standard

I don't see that "revert" is clearer than "reset".

Re: Reset buttons in Customize

[Luc Teirlinck]

Richard Stallman wrote:

       Revert to Saved
       Revert to Standard

   I don't see that "revert" is clearer than "reset".

OK, so what about:

Set for Current Session
Save for Future Sessions
Undo Edits
Revert to Saved
Erase Customization
Set to Backup value
--------------------------
Add Comment
--------------------------
Show Current Value
Show Saved Lisp Expression

Re: Reset buttons in Customize

[Luc Teirlinck]

   Richard Stallman wrote:

	  Revert to Saved
	  Revert to Standard

      I don't see that "revert" is clearer than "reset".

   OK, so what about:

   Set for Current Session
   Save for Future Sessions
   Undo Edits
   Revert to Saved
   Erase Customization
   Set to Backup value
   --------------------------
   Add Comment
   --------------------------
   Show Current Value
   Show Saved Lisp Expression

Instead of "Revert to Saved", I meant "Reset to Saved".  I just forgot
to change it what I killed and yanked.

Sincerely,

Luc.

Re: Reset buttons in Customize

[Luc Teirlinck]

I also propose to revert the recently changed State Menu for faces.
In particular:

Present (recently changed)      Original                  Proposed

Show all attributes      Show all display specs    Show all display specs
Show current attributes  Just current attributes   Just current display specs

Reason: unlike the old text, the new text "Show all attributes" does
not make clear what the "all" refers to: the value on other displays
than the current display.

"Show current attributes" seems to contrast with "saved" or "standard"
attributes, rather than point out that only the attributes for the
current display will be shown.

Sincerely,

Luc.

Re: Reset buttons in Customize

[Luc Teirlinck]

Maybe clearer than my previous suggestions:

Present (recently changed)      Original                  Proposed

Show all attributes     Show all display specs  Show specs for all displays
Show current attributes Just current attributes Just specs for current display

Sincerely,

Luc.

Re: Reset buttons in Customize

[Richard M. Stallman]

    Present (recently changed)      Original                  Proposed

    Show all attributes     Show all display specs  Show specs for all displays
    Show current attributes Just current attributes Just specs for current display

"Specs" is not clear, and those are annoyingly long.

I prefer

  Show Current Display
  Show All Kinds of Displays

Re: Reset buttons in Customize

[Luc Teirlinck]

Richard Stallman wrote:

   "Specs" is not clear, and those are annoyingly long.

   I prefer

     Show Current Display
     Show All Kinds of Displays

OK, so here is a summary of the proposed Sate Menus for variables and faces.

Variables:

Set for Current Session
Save for Future Sessions
Undo Edits
Reset to Saved
Erase Customization
Set to Backup value
--------------------------
Add Comment
--------------------------
Show Current Value
Show Saved Lisp Expression

Faces:

Set for Current Session
Save for Future Sessions
Reset to Saved
Erase Customization
------------------------
Add Comment
------------------------
Show Current Display
Show All Kinds of Displays
Show Current Lisp Expression

There is one accompanying change in the whole buffer buttons: Change
"Reset to Current" to "Undo Edits" in analogy with the State Menus.

As I already noted, it seems somewhat strange that there is no
"Undo Edits" in the Face State Menu.  I believe that this could be
easy to add, if desired.

If this looks OK now, I will also update the Emacs manual and some
other places for these changes.

Sincerely,

Luc.

Re: Reset buttons in Customize

[David Kastrup]

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

> Richard Stallman wrote:
>
>    "Specs" is not clear, and those are annoyingly long.
>
>    I prefer
>
>      Show Current Display
>      Show All Kinds of Displays

I don't think that makes much sense: it sounds like showing a
particular display instead of its specs...

I think that it would be less confusing to just write

For Current Display
For All Kinds of Displays

or even just

Current Display
All Kinds of Displays

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reset buttons in Customize

[Luc Teirlinck]

What about my earlier suggestions, which Richard probably has not seen
yet:

   Since the button says "Show Face", what about:

   Show Face for This Display
   Show Face for All Displays

That would give the following Face State Menu:

Set for Current Session
Save for Future Sessions
Reset to Saved
Erase Customization
------------------------
Add Comment
------------------------
Show Face for This Display
Show Face for All Displays
Show Current Lisp Expression

I believe that the two remaining questions are what to use for those
two lines in question and whether we should add a "Undo Edits" item to
the Face State Menu (assuming that this would be easy).

Sincerely,

Luc.

Re: Reset buttons in Customize

[Richard M. Stallman]

    >      Show Current Display
    >      Show All Kinds of Displays

    I don't think that makes much sense: it sounds like showing a
    particular display instead of its specs...

That literal-minded interpretation is not a real problem,
because people will get the point.  The other alternative,
which talks about "All Kinds", will help make it clear.

All the suggestions people have made for this have problems.
So I think that perfection here is too much to ask for.
We must be prepared to settle for the least bad.

    I think that it would be less confusing to just write

    For Current Display
    For All Kinds of Displays

That is a good idea.  I would be happy to use that.

Luc suggested:

       Since the button says "Show Face", what about:

       Show Face for This Display
       Show Face for All Displays

The added words are not particularly helpful.
I prefer "For Current Display".

Re: Reset buttons in Customize

[Luc Teirlinck]

Richard Stallman wrote:

       I think that it would be less confusing to just write

       For Current Display
       For All Kinds of Displays

   That is a good idea.  I would be happy to use that.

That is what I used.

       I wonder why faces do not have a "Undo Edits" (currently "Reset
       to Current") State item, like variables do.  It would be useful
       and I believe that it would be easy enough to add one.

   That is a bug--if you can fix it, please do.

I fixed it.

       `Anyway, I believe that "Show Lisp Expression" should be "Show
       Current Lisp expression", to prevent an obvious source of
       confusion: for variables, the _saved_ (or standard if no saved)
       Lisp expression is shown, for faces, the _current_ Lisp
       expression.

   I'd rather make it consistent, by changing what it does.

_For the time being_, I used "Show Saved Lisp Expression" for
variables and "Show Lisp Expression" for faces.  However, I will see
whether I can find a way to make the behavior consistent for variables
and faces without breaking anything else.  If so, these two names
could still be changed to reflect the new situation.

I will probably propose some code changes (and possibly accompanying
name changes) soon.

Sincerely,

Luc.

Re: Reset buttons in Customize

[Richard M. Stallman]

    _For the time being_, I used "Show Saved Lisp Expression" for
    variables and "Show Lisp Expression" for faces.  However, I will see
    whether I can find a way to make the behavior consistent for variables
    and faces without breaking anything else.  If so, these two names
    could still be changed to reflect the new situation.

Thanks in advance.

Re: Reset buttons in Customize

[Richard M. Stallman]

I think I agree with the change from "Reset to Current" to "Undo Edits".
But before we do it: does anyone object to that?

Re: Reset buttons in Customize

[Luc Teirlinck]

Richard Stallman wrote:

   I think I agree with the change from "Reset to Current" to "Undo Edits".
   But before we do it: does anyone object to that?

I installed this change yesterday evening before receiving your
message containing the quote above.  I have been asking whether there
were any objections against "Undo Edits" for eight days now (that was
seven yesterday), which is longer than usual, and I took the following
quote from one of your earlier messages as an OK to go ahead:

       Undo Edits

   Undo Edits seems clear at least.

There has been a lot of discussion on this thread already.  I believe
that I took all objections that have been formulated against my
various changes into account.  Any further objections would likely be
from people who did not read this thread and would only see the changes
after they were installed anyway, even if we waited still one extra week.

If there would be a flood of objections against "Undo Edits", we can
always change it back.

Sincerely,

Luc.

Re: Reset buttons in Customize

[Bill Wohler]

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

> I also propose to revert the recently changed State Menu for faces.
> In particular:
> 
> Present (recently changed)      Original                  Proposed
> 
> Show all attributes      Show all display specs    Show all display specs
> Show current attributes  Just current attributes   Just current display specs
> 
> Reason: unlike the old text, the new text "Show all attributes" does
> not make clear what the "all" refers to: the value on other displays
> than the current display.
> 
> "Show current attributes" seems to contrast with "saved" or "standard"
> attributes, rather than point out that only the attributes for the
> current display will be shown.

Only a programmer who has used defcustom will know what "specs" is.
Until recently, I didn't understand this menu item. I think the use of
"attributes" is far better for the user.

I agree wholeheartedly about your point about displays.

How about:

  Show Attributes for This Display
  Show Attributes for All Displays

Or:

  View >
    This Display
    All Displays
    
I just ventured into the Show All Attributes screen and was pretty
confused by the Display menu. It is not at all obvious what the "all",
"defaults", and "nil" items are supposed to represent. And what if you
have a face like mh-folder-tick with three displays (class
color)(background light), (class color)(background dark), and (class
color); what does it mean to set all of the Display menus to "all"? Or
"defaults"?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Reset buttons in Customize

[Luc Teirlinck]

Bill Wohler wrote:

   Only a programmer who has used defcustom will know what "specs" is.
   Until recently, I didn't understand this menu item. I think the use of
   "attributes" is far better for the user.

   I agree wholeheartedly about your point about displays.

   How about:

     Show Attributes for This Display
     Show Attributes for All Displays

"Attributes" is a long word, which makes the text long.  Since the
button says "Show Face", what about:

Show Face for This Display
Show Face for All Displays

Sincerely,

Luc.

Re: Reset buttons in Customize

[Bill Wohler]

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

> Bill Wohler wrote:
> 
>    Only a programmer who has used defcustom will know what "specs" is.
>    Until recently, I didn't understand this menu item. I think the use of
>    "attributes" is far better for the user.
> 
>    I agree wholeheartedly about your point about displays.
> 
>    How about:
> 
>      Show Attributes for This Display
>      Show Attributes for All Displays
> 
> "Attributes" is a long word, which makes the text long.  Since the
> button says "Show Face", what about:
> 
> Show Face for This Display
> Show Face for All Displays

I think that would be fine too.

You didn't like my even shorter "View This Display" idea? Or "Show This
Display"?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Reset buttons in Customize

[Luc Teirlinck]

Bill Wohler wrote:

   > Show Face for This Display
   > Show Face for All Displays

   I think that would be fine too.

   You didn't like my even shorter "View This Display" idea? Or "Show This
   Display"?

I think the added "Face for" makes things clearer.

Anyway, I believe that "Show Lisp Expression" should be
"Show Current Lisp expression", to prevent an obvious source of confusion:
for variables, the _saved_ (or standard if no saved) Lisp expression
is shown, for faces, the _current_ Lisp expression.  If we do that,
the Menu has to be wide enough to accomodate  "Show Current Lisp Expression"
anyway.  Proposed Face State Menu to complement the previously
proposed Variable State Menu:

Set for Current Session
Save for Future Sessions
Reset to Saved
Erase Customization
------------------------
Add Commment
------------------------
Show Face for This Display
Show Face for All Displays
Show Current Lisp Expression

I wonder why faces do not have a "Undo Edits" (currently "Reset to Current")
State item, like variables do.  It would be useful and I believe that
it would be easy enough to add one.

Sincerely,

Luc.

Re: Reset buttons in Customize

[Richard M. Stallman]

    Anyway, I believe that "Show Lisp Expression" should be
    "Show Current Lisp expression", to prevent an obvious source of confusion:
    for variables, the _saved_ (or standard if no saved) Lisp expression
    is shown, for faces, the _current_ Lisp expression.

I'd rather make it consistent, by changing what it does.

For instance, this menu item could be disabled for variables
if the variable's current value doesn't match the standard-or-saved
value.

    I wonder why faces do not have a "Undo Edits" (currently "Reset to Current")
    State item, like variables do.  It would be useful and I believe that
    it would be easy enough to add one.

That is a bug--if you can fix it, please do.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

   How about "Show Current Settings" or "Show Current Values"?

Apart from the possible sources of confusion I pointed out before,
this also could easily be misunderstood as meaning "Show hidden values",
which it does not.  Neither the current "Reset to Current" nor "Undo
Edits" or "Revert Edits" can be misunderstood in this sense.

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Luc Teirlinck]

Richard Stallman wrote:

       Maybe we could change "Reset to Current" to "Discard Edits", as
       somebody suggested at one point ("Reset to current" is not going to
       reset any setting, only text in the Custom buffer.)

   How about "Show Current Settings" or "Show Current Values"?
   And "Reset to Saved" could be "Show Saved Settings" or
   "Show Saved Values"?

These buttons do _not_ always show the current values.  So both the
current "Reset to Current" and your suggestions above are wrong.
What the buttons do is _undo the user's edits_.  To see the difference
do  `emacs -q' (under X) and `M-x customize-option RET tooltip-mode'.
It should be "on (non-nil)" which is STANDARD. 
  
Toggle to nil.  Set it for current session.  Select "Show as Lisp
expression" from the State button.  Now the saved value, (which
happens to be the standard value in this case) is shown as a Lisp
expression, which evaluates to t (which is why the recent change Chong
made is bad: it suggests that the current value, nil, would be shown
as a Lisp expression).

In addition to reverting or correcting Chong's change, I also suggest
to change the (lisp) which appears in the Custom buffer next to:

Set for current session only 

to:  (shown: saved Lisp expression)

to further reduce confusion.  Now edit the shown value and then select
"Reset to Current".  Now _not_ the current value is shown, but the
saved value as a Lisp expression.  So what the "Reset to Current"
button does is revert to whichever text occurred in the buffer before
your edits started.

So why not make it say what it really does:  "Revert Edits".

Sincerely,

Luc.

Re: Bug, probably related to Custom Themes.

[Richard M. Stallman]

    This completely untested patch may do what you want.

What does it do, in user terms?