* bug#70212: Customize Group buffer: add button to reveal underlying variable names @ 2024-04-05 8:45 Dan Jacobson 2024-04-05 12:27 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Dan Jacobson @ 2024-04-05 8:45 UTC (permalink / raw) To: 70212 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) ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#70212: Customize Group buffer: add button to reveal underlying variable names 2024-04-05 8:45 bug#70212: Customize Group buffer: add button to reveal underlying variable names Dan Jacobson @ 2024-04-05 12:27 ` Eli Zaretskii 2024-04-05 16:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-04-05 16:13 ` Juri Linkov 2024-04-14 16:27 ` Howard Melman 2 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 2024-04-05 12:27 UTC (permalink / raw) To: Dan Jacobson; +Cc: 70212 tags 70212 notabug close 70212 thanks > From: Dan Jacobson <jidanni@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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#70212: Customize Group buffer: add button to reveal underlying variable names 2024-04-05 12:27 ` Eli Zaretskii @ 2024-04-05 16:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 0 replies; 8+ messages in thread From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-05 16:32 UTC (permalink / raw) To: Eli Zaretskii, Dan Jacobson; +Cc: 70212@debbugs.gnu.org > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#70212: Customize Group buffer: add button to reveal underlying variable names 2024-04-05 8:45 bug#70212: Customize Group buffer: add button to reveal underlying variable names Dan Jacobson 2024-04-05 12:27 ` Eli Zaretskii @ 2024-04-05 16:13 ` Juri Linkov 2024-04-05 16:47 ` Kévin Le Gouguec 2024-04-14 16:27 ` Howard Melman 2 siblings, 1 reply; 8+ messages in thread From: Juri Linkov @ 2024-04-05 16:13 UTC (permalink / raw) To: Dan Jacobson; +Cc: 70212 > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#70212: Customize Group buffer: add button to reveal underlying variable names 2024-04-05 16:13 ` Juri Linkov @ 2024-04-05 16:47 ` Kévin Le Gouguec 2024-04-05 17:13 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 8+ messages in thread From: Kévin Le Gouguec @ 2024-04-05 16:47 UTC (permalink / raw) To: Juri Linkov; +Cc: 70212, Dan Jacobson Juri Linkov <juri@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'). ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#70212: Customize Group buffer: add button to reveal underlying variable names 2024-04-05 16:47 ` Kévin Le Gouguec @ 2024-04-05 17:13 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-04-06 6:40 ` Dan Jacobson 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-05 17:13 UTC (permalink / raw) To: Kévin Le Gouguec, Juri Linkov; +Cc: Dan Jacobson, 70212@debbugs.gnu.org > > 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. ;-) ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#70212: Customize Group buffer: add button to reveal underlying variable names 2024-04-05 17:13 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-06 6:40 ` Dan Jacobson 0 siblings, 0 replies; 8+ messages in thread From: Dan Jacobson @ 2024-04-06 6:40 UTC (permalink / raw) To: Drew Adams; +Cc: 70212@debbugs.gnu.org, Juri Linkov, Kévin Le Gouguec 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#70212: Customize Group buffer: add button to reveal underlying variable names 2024-04-05 8:45 bug#70212: Customize Group buffer: add button to reveal underlying variable names Dan Jacobson 2024-04-05 12:27 ` Eli Zaretskii 2024-04-05 16:13 ` Juri Linkov @ 2024-04-14 16:27 ` Howard Melman 2 siblings, 0 replies; 8+ messages in thread From: Howard Melman @ 2024-04-14 16:27 UTC (permalink / raw) To: 70212 Dan Jacobson <jidanni@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-04-14 16:27 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-04-05 8:45 bug#70212: Customize Group buffer: add button to reveal underlying variable names Dan Jacobson 2024-04-05 12:27 ` Eli Zaretskii 2024-04-05 16:32 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-04-05 16:13 ` Juri Linkov 2024-04-05 16:47 ` Kévin Le Gouguec 2024-04-05 17:13 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-04-06 6:40 ` Dan Jacobson 2024-04-14 16:27 ` Howard Melman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.