GNU bug report logs -
#70212
Customize Group buffer: add button to reveal underlying variable names
Previous Next
Reported by: Dan Jacobson <jidanni <at> jidanni.org>
Date: Fri, 5 Apr 2024 08:47:01 UTC
Severity: normal
Tags: notabug
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 70212 in the body.
You can then email your comments to 70212 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70212
; Package
emacs
.
(Fri, 05 Apr 2024 08:47:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dan Jacobson <jidanni <at> jidanni.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 05 Apr 2024 08:47:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The user is in buffer
*Customize Group: Compilation*
The user sees:
Show Value Compilation Max Output Line Length
Output lines that are longer than this value will be hidden. Hide
If nil, don’t hide anything.
Try as the user might, there is no way for him to discover the
underlying variable there in the interface.
All he can do is do C-h v and start guessing its name. Finally arriving at
(describe-variable 'compilation-max-output-line-length)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70212
; Package
emacs
.
(Fri, 05 Apr 2024 12:28:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 70212 <at> debbugs.gnu.org (full text, mbox):
tags 70212 notabug
close 70212
thanks
> From: Dan Jacobson <jidanni <at> jidanni.org>
> Date: Fri, 05 Apr 2024 16:45:48 +0800
>
> The user is in buffer
> *Customize Group: Compilation*
>
> The user sees:
> Show Value Compilation Max Output Line Length
> Output lines that are longer than this value will be hidden. Hide
> If nil, don’t hide anything.
>
> Try as the user might, there is no way for him to discover the
> underlying variable there in the interface.
That's not how users are supposed to find out variable names. The
Customize user interface is for users who don't need to know the Lisp
name of a variable. You can customize this (and any other) variable
without knowing its Lisp name; forf all practical purposes its name is
"Compilation Max Output Line Length", which is written right there.
Which is why this UI doesn't mention the Lisp names of variables: they
might confuse users who don't know Lisp.
> All he can do is do C-h v and start guessing its name. Finally arriving at
The most efficient way of finding out the Lisp name of the variable is
to type:
M-x apropos-variable RET Compilation Max Output Line Length RET
So I'm closing this bug as it is not a bug at all: Emacs behaves as
intended here.
Added tag(s) notabug.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 05 Apr 2024 12:33:03 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
70212 <at> debbugs.gnu.org and Dan Jacobson <jidanni <at> jidanni.org>
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 05 Apr 2024 12:33:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70212
; Package
emacs
.
(Fri, 05 Apr 2024 16:15:01 GMT)
Full text and
rfc822 format available.
Message #15 received at 70212 <at> debbugs.gnu.org (full text, mbox):
> The user is in buffer
> *Customize Group: Compilation*
>
> The user sees:
> Show Value Compilation Max Output Line Length
> Output lines that are longer than this value will be hidden. Hide
> If nil, don’t hide anything.
>
> Try as the user might, there is no way for him to discover the
> underlying variable there in the interface.
You can read the related discussion at bug#41905.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70212
; Package
emacs
.
(Fri, 05 Apr 2024 16:34:03 GMT)
Full text and
rfc822 format available.
Message #18 received at 70212 <at> debbugs.gnu.org (full text, mbox):
> tags 70212 notabug
> close 70212
> thanks
>
> > The user is in buffer *Customize Group: Compilation*
> >
> > The user sees:
> > Show Value Compilation Max Output Line Length
> > Output lines that are longer than this value will be hidden. Hide
> > If nil, don’t hide anything.
> >
> > Try as the user might, there is no way for him to discover the
> > underlying variable there in the interface.
>
> That's not how users are supposed to find out variable names. The
> Customize user interface is for users who don't need to know the Lisp
> name of a variable. You can customize this (and any other) variable
> without knowing its Lisp name; forf all practical purposes its name is
> "Compilation Max Output Line Length", which is written right there.
> Which is why this UI doesn't mention the Lisp names of variables: they
> might confuse users who don't know Lisp.
>
> > All he can do is do C-h v and start guessing its name. Finally
> > arriving at
>
> The most efficient way of finding out the Lisp name of the variable is
> to type:
>
> M-x apropos-variable RET Compilation Max Output Line Length RET
>
> So I'm closing this bug as it is not a bug at all: Emacs behaves as
> intended here.
If the point of view is "that's not how users are
supposed to find out variable names", then Emacs
isn't being as helpful as it could be.
Emacs could easily be more helpful by bridging the
discovery gap that you expose by saying, correctly:
> forf all practical purposes its name is
> "Compilation Max Output Line Length",
> which is written right there.
Yes, it's written right there. But it's not obvious
that it's written right there. So it's not the case
for all practical purposes.
`M-x apropos variable' is fine, but it shouldn't be
necessary to know about that command, and use it
here, to get the variable name in its usual form
(Lisp): `compilation-max-output-line-length'.
It would be helpful if Emacs made that UI name,
`Compilation Max Output Line Length' a button that
toggled option `custom-unlispify-tag-names', thus
immediately changing what's shown to the variable
name as expected by Emacs's help commands etc.:
`compilation-max-output-line-length'. A button's
quite discoverable, and would be tried.
It would help further if the colon were removed
after `compilation-max-output-line-length'. Then
you could just use `C-h v', and the default value
would be `compilation-max-output-line-length'.
(That suggestion was made in bug #3395, but it was
rejected summarily.)
At least users can use `C-h S' on the option name,
whether it's shown as `Compilation Max Output Line
Length' or `compilation-max-output-line-length'.
But users need to know they can do that... Again,
not obvious.
Helping users discover _how to ask Emacs_ has
been, and should always be, one of Emacs's highest
priorities.
In this case, it would be easy to make things
easier for users. Just saying "The most efficient
way of finding out the Lisp name" doesn't help
users who haven't a clue about that command.
Throughout the manual, and elsewhere, users can
use apropos commands to find more info about
something they come across. But we could also
make it easier to find such info when what they
want to know about is in fact "written right
there" but they might not be aware of that.
(Just one opinion.)
___
Related:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3395
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=1478
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70212
; Package
emacs
.
(Fri, 05 Apr 2024 16:49:03 GMT)
Full text and
rfc822 format available.
Message #21 received at 70212 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> The user is in buffer
>> *Customize Group: Compilation*
>>
>> The user sees:
>> Show Value Compilation Max Output Line Length
>> Output lines that are longer than this value will be hidden. Hide
>> If nil, don’t hide anything.
>>
>> Try as the user might, there is no way for him to discover the
>> underlying variable there in the interface.
>
> You can read the related discussion at bug#41905.
And bug#400 (referenced in bug#41905).
FWIW I agree making Custom > Help navigation more seamless would be
neat; one may first be interested in browsing options via Customize's
group hierarchies, then jump to a Help buffer to seek details about a
specific variables (:version, estimated introductory release) or use
help-mode-map commands (e.g. 'i', 's').
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70212
; Package
emacs
.
(Fri, 05 Apr 2024 17:14:01 GMT)
Full text and
rfc822 format available.
Message #24 received at 70212 <at> debbugs.gnu.org (full text, mbox):
> > You can read the related discussion at bug#41905.
>
> And bug#400 (referenced in bug#41905).
I'd forgotten about that one; thankx. The other
two I mentioned were just closed as "won't fix".
That one has hung on as "wishlist".
> FWIW I agree making Custom > Help navigation more seamless would be
> neat; one may first be interested in browsing options via Customize's
> group hierarchies, then jump to a Help buffer to seek details about a
> specific variables (:version, estimated introductory release) or use
> help-mode-map commands (e.g. 'i', 's').
Yup. More seamless - less seamful - would help. ;-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70212
; Package
emacs
.
(Sat, 06 Apr 2024 06:41:01 GMT)
Full text and
rfc822 format available.
Message #27 received at 70212 <at> debbugs.gnu.org (full text, mbox):
All I'm saying is the user is just inches from being able to find a
treasure trove of more information on the thing he is looking at
if only there was a button, sure, fitted with a safety cap perhaps,
to do it. Fine, label it as the gory details button.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#70212
; Package
emacs
.
(Sun, 14 Apr 2024 16:29:01 GMT)
Full text and
rfc822 format available.
Message #30 received at submit <at> debbugs.gnu.org (full text, mbox):
Dan Jacobson <jidanni <at> jidanni.org> writes:
> The user is in buffer
> *Customize Group: Compilation*
>
> The user sees:
> Show Value Compilation Max Output Line Length
> Output lines that are longer than this value will be hidden. Hide
> If nil, don’t hide anything.
>
> Try as the user might, there is no way for him to discover the
> underlying variable there in the interface.
The user could click the State button and select "Show Saved
Lisp Expression" which will also convert values such as shown
in that group for the "Compilation Scroll Output" option.
--
Howard
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 13 May 2024 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.