unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>, Dan Jacobson <jidanni@jidanni.org>
Cc: "70212@debbugs.gnu.org" <70212@debbugs.gnu.org>
Subject: bug#70212: Customize Group buffer: add button to reveal underlying variable names
Date: Fri, 5 Apr 2024 16:32:48 +0000	[thread overview]
Message-ID: <SJ0PR10MB54885E5782DD7AF18CA72EABF3032@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <86il0w5711.fsf@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


  reply	other threads:[~2024-04-05 16:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB54885E5782DD7AF18CA72EABF3032@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=70212@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=jidanni@jidanni.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).