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

[Drew Adams <drew.adams@oracle.com>]

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