bug#12065: 24.1; `custom-magic-show': set to "no", cannot get back again

bug#12065: 24.1; `custom-magic-show': set to "no", cannot get back again

[Drew Adams]

emacs -Q
 
M-x customize-option custom-magic-show
 
Change the value to "no" using Value Menu.
Choose Set for Current Session.

You can never change it back to another value, because there is no State
button.
 

In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
 of 2012-06-10 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

bug#12065: 24.1; `custom-magic-show': set to "no", cannot get back again

[Drew Adams]

ping

bug#12065: 24.1; `custom-magic-show': set to "no", cannot get back again

[npostavs]

severity 12065 minor
tags 12065 notabug
quit

"Drew Adams" <drew.adams@oracle.com> writes:

> emacs -Q
>  
> M-x customize-option custom-magic-show
>  
> Change the value to "no" using Value Menu.
> Choose Set for Current Session.
>
> You can never change it back to another value, because there is no State
> button.

Apart from doing a setq manually, there is an "Apply" (it's labeled "Set
for current session" in 24.1) button at the top of the buffer.

bug#12065: 24.1; `custom-magic-show': set to "no", cannot get back again

[Drew Adams]

> > emacs -Q
> >
> > M-x customize-option custom-magic-show
> >
> > Change the value to "no" using Value Menu.
> > Choose Set for Current Session.
> >
> > You can never change it back to another value, because there is no State
> > button.
> 
> Apart from doing a setq manually, there is an "Apply" (it's labeled "Set
> for current session" in 24.1) button at the top of the buffer.

Huh?  I don't understand how that means that this is not a bug.
You might not have the will or resources to fix this now, but
this certainly must be a bug.

If a user can change the value using the Value menu then it
should be possible to change it back again, _using the Value
menu_.

It makes no difference that there might be other ways to change
it back.  This bug is about using the Value menu (and then the
State menu).

The point of this bug is that using the Value menu is a one-way
street, exceptionally, in the case of this one option.  That's
not normal - why should this option be an exception to how
Emacs Customize works?  And if you change the value to short
or long there is no such problem.

Using the Value menu to change the value to no should make the
State menu disappear.  Period.  (And the State menu is used
for multiple purposes, not just to set the value for the
current session.)

bug#12065: 24.1; `custom-magic-show': set to "no", cannot get back again

[npostavs]

Drew Adams <drew.adams@oracle.com> writes:
> The point of this bug is that using the Value menu is a one-way
> street, exceptionally, in the case of this one option.  That's
> not normal - why should this option be an exception to how
> Emacs Customize works?  And if you change the value to short
> or long there is no such problem.

I thought maybe the point of that option is to hide the button.  It's
easy enough to exclude the button from hiding, just move that code
outside of the conditional:

diff --git i/lisp/cus-edit.el w/lisp/cus-edit.el
index ef12745..de219cb 100644
--- i/lisp/cus-edit.el
+++ w/lisp/cus-edit.el
@@ -2053,24 +2053,24 @@ custom-magic-value-create
 	(setq text (concat (match-string 1 text)
 			   (symbol-name category)
 			   (match-string 2 text))))
+      (insert "   ")
+      (when (and (eq category 'group)
+                 (not (and (eq custom-buffer-style 'links)
+                           (> (widget-get parent :custom-level) 1))))
+        (insert-char ?\s (* custom-buffer-indent
+                            (widget-get parent :custom-level))))
+      (push (widget-create-child-and-convert
+             widget 'choice-item
+             :help-echo "Change the state of this item."
+             :format (if hidden "%t" "%[%t%]")
+             :button-prefix 'widget-push-button-prefix
+             :button-suffix 'widget-push-button-suffix
+             :mouse-down-action 'widget-magic-mouse-down-action
+             :tag " State ")
+            children)
       (when (and custom-magic-show
 		 (or (not hidden)
 		     (memq category custom-magic-show-hidden)))
-	(insert "   ")
-	(when (and (eq category 'group)
-		   (not (and (eq custom-buffer-style 'links)
-			     (> (widget-get parent :custom-level) 1))))
-	  (insert-char ?\s (* custom-buffer-indent
-			      (widget-get parent :custom-level))))
-	(push (widget-create-child-and-convert
-	       widget 'choice-item
-	       :help-echo "Change the state of this item."
-	       :format (if hidden "%t" "%[%t%]")
-	       :button-prefix 'widget-push-button-prefix
-	       :button-suffix 'widget-push-button-suffix
-	       :mouse-down-action 'widget-magic-mouse-down-action
-	       :tag " State ")
-	      children)
 	(insert ": ")
 	(let ((start (point)))
 	  (if (eq custom-magic-show 'long)
@@ -2080,8 +2080,8 @@ custom-magic-value-create
 		 (insert " (lisp)"))
 		((eq form 'mismatch)
 		 (insert " (mismatch)")))
-	  (put-text-property start (point) 'face 'custom-state))
-	(insert "\n"))
+	  (put-text-property start (point) 'face 'custom-state)))
+      (insert "\n")
       (when (and (eq category 'group)
 		 (not (and (eq custom-buffer-style 'links)
 			   (> (widget-get parent :custom-level) 1))))

bug#12065: 24.1; `custom-magic-show': set to "no", cannot get back again

[Drew Adams]

> > The point of this bug is that using the Value menu is a one-way
> > street, exceptionally, in the case of this one option.  That's
> > not normal - why should this option be an exception to how
> > Emacs Customize works?  And if you change the value to short
> > or long there is no such problem.
> 
> I thought maybe the point of that option is to hide the button.

The doc talks about the "textual description of the state."
And `long' and `short' have the effect of providing a long
and short description of the current state - to the right of
the State button.

The doc says nothing about what a `no' (`nil') value means.
But by analogy with the effects of `long' and `short', and by
interpretation of "textual description of the state" as being
the text to the right of the button, which describes the
current state, presumably `no' (`nil') would mean no textual
description of the current state.

That has nothing to do with no State button (which does not
describe the current  state but instead lets you perform 
various Customize actions, including change the state.

> It's easy enough to exclude the button from hiding, just
> move that code outside of the conditional

I have nothing to say about how to fix the bug.  I only
reported the problem.

bug#12065: 24.1; `custom-magic-show': set to "no", cannot get back again

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Date: Fri, 05 Aug 2016 20:25:23 -0400
> Cc: 12065@debbugs.gnu.org
> 
> I thought maybe the point of that option is to hide the button.

It is.

bug#12065: 24.1; `custom-magic-show': set to "no", cannot get back again

[Eli Zaretskii]

tags 12065 + notabug
thanks

> Date: Fri, 5 Aug 2016 17:03:51 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 12065@debbugs.gnu.org
> 
> > Apart from doing a setq manually, there is an "Apply" (it's labeled "Set
> > for current session" in 24.1) button at the top of the buffer.
> 
> Huh?  I don't understand how that means that this is not a bug.

You've misunderstood what Noam was saying, that's all.

> You might not have the will or resources to fix this now, but
> this certainly must be a bug.

And this is an uncalled-for attack.  Are you working on acquiring yet
another member of the project who will not want to work on your bug
reports?  If so, you are on the right path.

> If a user can change the value using the Value menu then it
> should be possible to change it back again, _using the Value
> menu_.

What Noam tells you is this: if you click "Apply" after selecting any
other value, the "State" button reappears.  And the help-echo on the
"Apply" and "Apply and Save" buttons is also revealing.

> It makes no difference that there might be other ways to change
> it back.  This bug is about using the Value menu (and then the
> State menu).

There is no bug that I can see, Emacs is behaving as documented and as
expected, since hiding that button is part of what the nil value does.

> The point of this bug is that using the Value menu is a one-way
> street, exceptionally, in the case of this one option.

No, it isn't.  See above.

> That's not normal - why should this option be an exception to how
> Emacs Customize works?

Because that's its purpose.

> And if you change the value to short or long there is no such
> problem.

Indeed, as documented.

> Using the Value menu to change the value to no should make the
> State menu disappear.  Period.

That's what Emacs does.

bug#12065: 24.1; `custom-magic-show': set to "no", cannot get back again

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 12065 + notabug
> thanks
[...]
> There is no bug that I can see, Emacs is behaving as documented and as
> expected, since hiding that button is part of what the nil value does.

This was tagged notabug.  I agree with the rationale and I'm
therefore now also closing this bug.

Best regards,
Stefan Kangas

bug#12065: 24.1; `custom-magic-show': set to "no", cannot get back again

[Drew Adams]

> > I don't understand how that means that this is not a bug.
>
> You've misunderstood what Noam was saying, that's all.
>
> > You might not have the will or resources to fix this now,
> > but this certainly must be a bug.
> 
> And this is an uncalled-for attack.  Are you working on acquiring yet
> another member of the project who will not want to work on your bug
> reports?  If so, you are on the right path.

*That* is an unwarranted attack.  Are you working on convincing
Noam that he should not work on bugs I report?

My point was (1) that it is _fine_ to (a) *not want* to work
on a particular bug, or to want to but (b) *not have the time*
to.  And that that is _expected_, particularly for bugs that
are judged to be minor and whose fixes might not be minor.

(2) But that, in itself, is not a reason to close a bug.
A bug can remain open without getting immediate attention
to fix it.  That was my point (1 & 2).  There is nothing
"attacking" in what I said, and nothing ad hominem.

Your response, on the other hand...

FWIW, I don't have any problem with what I've seen of Noam's
work on fixing bugs or his attitude or approach to doing so.
On the contrary.  And I thank him for helping.

I did not (and do not) see how there being an "Apply" button,
or being able to `setq' the variable, means that there is no
bug here.  That was a reason given as to why there is no bug,
and to me that is no reason.  If `defun' stopped working it
would not be appropriate to say that there was no bug because
you can just use `fset'.

> > Using the Value menu to change the value to no should
> > [not] make the State menu disappear.
    ^^^^^
     typo - missed this; sorry

> There is no bug that I can see, Emacs is behaving as
> documented and as expected, since hiding that button is
> part of what the nil value does.

I see.  I haven't located that documentation.  Where does
Emacs say that?  The doc string certainly doesn't say it.
And there is nothing in the manuals about it.

In fact, the doc says _nothing_ about the behavior when
the value is nil (as the bug report mentions).

You can guess, from the description of non-nil, that nil
means to not show the "textual description of the state".
But that description is the text near the State button,
which describes the current state.  It is not the State
button itself.

That is not what the State button does - the button is not
a textual description, and it does not describe the current
state.

If what you say is really the intention, then the doc should
say that nil removes the State button as well as the textual
description of the current state.

Otherwise, users are likely to be as surprised and confused
as I was when I stumbled on this unusual behavior, and wonder
how to get back the State button (which does more than just
set the option value for the current session).  Both what nil
does to the State button, and how to get it back, should be
made clear in the doc.

I'd argue that the current behavior wrt hiding the State
button, whether intended or not, is bad - user unfriendly.
But if you like it, please fix the doc so it lets users know
just what to expect.  Thx.