bug#400: 23.0.60; C-h v should pick up lispified name in Customize

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

emacs -Q
M-x customize-option Info-hide-note-references
 
Put the cursor on the unlispified option name:
Info Hide Note References.
 
C-h v
 
The option name is not picked up as the default value. All commands,
such as `describe-variable', that ask the user to input a variable
name should use the lispified name as the default value:
Info-hide-note-references, in this case.
 
The way this should be treated generally is that `Info Hide Note
References' should simply be the _displayed form_ of the
variable. Under the covers, Emacs should always see the true variable
name.
 

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-05-29 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
 

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[martin rudalics]

 > M-x customize-option Info-hide-note-references
 >
 > Put the cursor on the unlispified option name:
 > Info Hide Note References.
 >
 > C-h v
 >
 > The option name is not picked up as the default value. All commands,
 > such as `describe-variable', that ask the user to input a variable
 > name should use the lispified name as the default value:
 > Info-hide-note-references, in this case.
 >
 > The way this should be treated generally is that `Info Hide Note
 > References' should simply be the _displayed form_ of the
 > variable. Under the covers, Emacs should always see the true variable
 > name.

Look at what I did in `info-lookup-guess-custom-symbol'.  Not that I'm
particularly proud of it.  Maybe you can find a cleaner solution.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

> Look at what I did in `info-lookup-guess-custom-symbol'.  Not that I'm
> particularly proud of it.  Maybe you can find a cleaner solution.

I don't know where that is.

In any case, I don't care how it's done, but it would be good to do this, if
possible.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Lars Ingebrigtsen]

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

> emacs -Q
> M-x customize-option Info-hide-note-references
>
> Put the cursor on the unlispified option name:
> Info Hide Note References.
>
> C-h v
>
> The option name is not picked up as the default value.

The command just calls variable-at-point, which doesn't have any
machinery to go from the displayed data to the actual symbol (which
info-look has).

It's trivial to fix (now after bug#41905 was fixed), but I'm not sure at
what level to do that.  The least invasive way to do it would be to just
redefine `C-h v' in Customize buffers, but the way `describe-variable'
is defined would require a refactor of that function.

`variable-at-point' could grow some way to allow it to be parameterised,
for instance via a buffer-local variable-at-point-function, which would
be kinda clean and is how many similar things are handled... 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 06 Sep 2020 14:26:35 +0200
> Cc: 400@debbugs.gnu.org
> 
> "Drew Adams" <drew.adams@oracle.com> writes:
> 
> > emacs -Q
> > M-x customize-option Info-hide-note-references
> >
> > Put the cursor on the unlispified option name:
> > Info Hide Note References.
> >
> > C-h v
> >
> > The option name is not picked up as the default value.

I don't see how using "C-h v" in that case is a reasonable use case,
since the documentation is displayed right below the name of the
option.

We could perhaps have a help command that recognized names of
variables in this format, but then it shouldn't be "C-h v", IMO, since
that command talks about _variables_, whereas a name such as "Info
Hide Note References" is not a variable name.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't see how using "C-h v" in that case is a reasonable use case,
> since the documentation is displayed right below the name of the
> option.

FWIW, the *Help* buffer has a few perks over the *Customize* buffer:

- it contains a link to the variable's definition,

- it displays the variable's original value,

- it displays the option's :version property, as well as the estimated
  release that introduced it,

- symbols mentioned in the docstring are buttonized
  (e.g. Info-refill-paragraphs in Info-hide-note-references's
  docstring).

Not that those features couldn't be added to the *Customize* buffer in
principle; as things stand though, I could see myself wanting to jump
from the *Customize* buffer to the *Help* buffer for any of these
reasons, and it'd be nice if "C-h v RET" did the right thing.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't see how using "C-h v" in that case is a reasonable use case,
> since the documentation is displayed right below the name of the
> option.
>
> We could perhaps have a help command that recognized names of
> variables in this format, but then it shouldn't be "C-h v", IMO, since
> that command talks about _variables_, whereas a name such as "Info
> Hide Note References" is not a variable name.

I appreciate the merits of this point of view, but at the same time it
would be kind of nice with some DWIM here.

I for one have gone through switching unlispify off, because it is
faster to hit `C-h v RET' (firmly committed to muscle memory) than
fiddling around with however it is you expand the documentation in a
customize buffer; I guess the fastest way is C-a RET TAB TAB TAB (until
point lands on "More") and then RET again.

But then I switched back again, because with the unlispified names I
found it easier to skim the buffer and quickly find what I want...

So I think I would actually appreciate this feature, in particular if it
was on `C-h v' because that's what I use everywhere else for variables.
Even if it could perhaps be considered a bit "unclean".

bug#400: [External] : Re: bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

> So I think I would actually appreciate this feature, in particular if
> it was on `C-h v' because that's what I use everywhere else for variables.
> Even if it could perhaps be considered a bit "unclean".

Yes.  (But I don't see anything unclean about it.)

In this context (customizing options) I use `C-h v'
and then `M-.', which with Icicles puts the name at
point in the minibuffer.  Then I backspace to remove
the `:' char (which should anyway not be used there;
it's just noise and a bother).

Eli says this isn't reasonable because the doc is
already displayed in Customize.  It is displayed
(though it might be partially hidden), but without
its _links_.  Being shown there is no substitute
for *Help*.

(To me this request should have been a no-brainer.
But what do I know?)
___

I also think that `custom-unlispify-tag-names'
should be OFF by default.

Or that the Lisp names should _always_ be shown.
If you want to also show the unlispified names
then OK, do so (but have an option to turn that
off).

The Lisp name is what's useful to users - all
users.  The "unlispified" name is ~useless.  OK,
in some cases it might convey something helpful.
But that can be done without removing the Lisp
name.  The Lisp name is paramount, and being
able to use it to get to more info is important.
___

Another possibility, if the Lisp name is shown,
is to make it a link to what `C-h v' shows.  (Or
a link to what `C-h S' shows.)

bug#400: [External] : Re: bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: Lars Ingebrigtsen <larsi@gnus.org>,
>         "400@debbugs.gnu.org"
> 	<400@debbugs.gnu.org>
> Date: Wed, 20 Oct 2021 21:27:41 +0000
> 
> Eli says this isn't reasonable because the doc is
> already displayed in Customize.  It is displayed
> (though it might be partially hidden), but without
> its _links_.  Being shown there is no substitute
> for *Help*.

And why is that a problem?  Customize is not for people who will look
at the code, Customize is for people who want easy customizations,
which presumes new users.  Any particular reason why would they so
sorely miss what *Help* adds to the doc string?

However, we could extend "C-h v" to take the default from the variable
being customized in the current Custom buffer, if there's nothing
appropriate at point.  Would that be okay?

> I also think that `custom-unlispify-tag-names'
> should be OFF by default.

I disagree, again because this feature targets new users, for whom the
Lisp-style names could very well be confusing and alien.

> The Lisp name is what's useful to users - all
> users.

DISAGREE!!  That's not how this feature is designed to work; your
opinions are noted, but they are against the spirit of Customize.

bug#400: [External] : Re: bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

> > Eli says this isn't reasonable because the doc is
> > already displayed in Customize.  It is displayed
> > (though it might be partially hidden), but without
> > its _links_.  Being shown there is no substitute
> > for *Help*.
> 
> And why is that a problem?  Customize is not for people
> who will look at the code,

Code?

> Customize is for people who want easy customizations,
> which presumes new users.

Customize is for everyone, new users included.

Anyone who appreciates immediate info about
option values, interactive choice of colors etc.,
type control/checking, taking care of accessory
initialization or setting operations, saving, etc.

> Any particular reason why would they so
> sorely miss what *Help* adds to the doc string?

Why new users would sorely miss what *Help* offers?

Dunno about "sorely", but same reasons that *Help*
bothers to offer what it does - links to related
things (including other user options, commands to
toggle options, etc.).

When you customize an option you might want to
understand it - know more about it.  That's what
*Help* is for.

And as I mentioned, an alternative to linking to
*Help* could be to link to the manual.  Or the
manual if doc'd there and *Help* if not.  Or
bring up both.  The real point is that from
Customize give users a quick way to get to more
info about the option (or face).

> However, we could extend "C-h v" to take the default from the variable
> being customized in the current Custom buffer, if there's nothing
> appropriate at point.  Would that be okay?

Okay?  I can't speak to what compromise is OK.

`C-h v' should, IMO, as usual provide as default
the variable name at point.  You can use it on
another variable mentioned in the doc shown, for
example.

But yes, _with point on the option name_,
`C-h v' should use that as default value.

> > I also think that `custom-unlispify-tag-names'
> > should be OFF by default.
> 
> I disagree, again because this feature targets new users, for whom the
> Lisp-style names could very well be confusing and alien.

1. Customize doesn't target only new users.
2. New users need to talk with Emacs about options
   using their (real) names.

   That's not about Lisp, per se.  It's about the
   _option name_.  Only the option name is an entry
   point to info about the option.

Option names are not something that only lispers
use or only they should use or have knowledge of.
The more immediately we introduce a user (new or
old) to the _actual name_ of an option, the more
we help them.  The more we obscure that name, the
more we do users (new and old) a disservice.

The substitution of capitalized, space-separated
"words" for the actual name of an option in
Customize is one of the _worst_ - perhaps the
worst - UI decision made for Emacs design.

It should be removed altogether - it confuses
rather than helps.  I can think of no way in
which it helps anyone - _especially_ new users.
It just hides the option name behind some awful,
useless chrome - chrome that has less, not more,
meaning than the real name.

On this one, I guess we'll just have to agree
to disagree.

> > The Lisp name is what's useful to users -
> > all users.
> 
> DISAGREE!!  That's not how this feature is designed to work; your
> opinions are noted, but they are against the spirit of Customize.

You decide for Emacs.  But I don't think you can
really speak for "the spirit of Customize".  Not
more than others.  That's the way it is, sorry.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> So I think I would actually appreciate this feature, in particular if it
> was on `C-h v' because that's what I use everywhere else for variables.

What about making the unlispified variable name into a button?  It could
offer to take you to *Help* or to *info*, for instance.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> So I think I would actually appreciate this feature, in particular if it
>> was on `C-h v' because that's what I use everywhere else for variables.
>
> What about making the unlispified variable name into a button?  It could
> offer to take you to *Help* or to *info*, for instance.

It might work.  My concern would be that it would risk making this
already button-heavy buffer even more noisy.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> It might work.  My concern would be that it would risk making this
> already button-heavy buffer even more noisy.

It makes TAB-ing around awkward -- but as you say, there's already a lot
of buttons in these buffers, so TAB is already ... less than ideal.

So adding more buttons doesn't make things a lot worse.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#400: [External] : Re: bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

Funny how you carry on a dialog between yourselves,
doing your best to ignore my input, even for bugs I
filed, and even when you end up parroting what I've
said as if it occurred to you.  Oh well.

At least you're noticing the problem now, after 13
years.  Now how about doing the right thing?

bug#400: [External] : Re: bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: Eli Zaretskii <eliz@gnu.org>, "400@debbugs.gnu.org" <400@debbugs.gnu.org>
> Date: Thu, 21 Oct 2021 05:01:47 +0000
> 
> Funny how you carry on a dialog between yourselves,
> doing your best to ignore my input, even for bugs I
> filed, and even when you end up parroting what I've
> said as if it occurred to you.  Oh well.

Please stop your unkind and sarcastic attacks against people who do
their best to handle your bug reports.

> At least you're noticing the problem now, after 13
> years.  Now how about doing the right thing?

How about trusting us we do?

Or if not, how about realizing that tis very anti-social behavior is
_why_ you think your inputs are ignored?

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> It might work.  My concern would be that it would risk making this
>> already button-heavy buffer even more noisy.
>
> It makes TAB-ing around awkward -- but as you say, there's already a lot
> of buttons in these buffers, so TAB is already ... less than ideal.

Right.  We should probably add in more navigation commands in that
buffer as well.  "n" and "p" are already bound to `widget-forward', but
they would have been perfect candidates for a "go to next item" command.
Now they just give the same clunky behavior as with TAB.

> So adding more buttons doesn't make things a lot worse.  :-)

I guess we could try it and see.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Right.  We should probably add in more navigation commands in that
> buffer as well.  "n" and "p" are already bound to `widget-forward', but
> they would have been perfect candidates for a "go to next item" command.
> Now they just give the same clunky behavior as with TAB.

Yeah, that sounds good -- duplicating the widget movements on the
non-standard `n'/`p' bindings is confusing, anyway.

>> So adding more buttons doesn't make things a lot worse.  :-)
>
> I guess we could try it and see.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#400: [External] : Re: bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

> > Right.  We should probably add in more navigation commands in that
> > buffer as well.  "n" and "p" are already bound to `widget-forward',
> but
> > they would have been perfect candidates for a "go to next item"
> command.
> > Now they just give the same clunky behavior as with TAB.
> 
> Yeah, that sounds good -- duplicating the widget movements on the
> non-standard `n'/`p' bindings is confusing, anyway.
> 
> >> So adding more buttons doesn't make things a lot worse.  :-)
> >
> > I guess we could try it and see.
> 
> Yup.

1. Please, navigation is not what _this_ bug report
   is about.  Please discuss navigation possibilities
   elsewhere, and take care of them there.

2. Wrt that navigation discussion (add this to that
   new discussion elsewhere, when you start it):

   There are other keys used for navigation, which
   could be to move among different kinds of things
   (e.g. Customize entries: options, faces in a group).
   Dired uses `>', `<' for one kind of movement, and
   `C-M-n', `C-M-p' for another (in addition to `n',
   `p', for a third.

But please do respect #1.  This bug thread is not the
place to introduce miscellaneous possible Customize
enhancements or other Customize bugs.

bug#400: [External] : Re: bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

> What about making the unlispified variable name into a button?  It
> could offer to take you to *Help* or to *info*, for instance.

Please read what I wrote about that today.

The Lisp name should appear (always), whether
the phony, non-Lisp "name" appears or not, and
whether or not the name is a link ("button")
to the real *Help*.

Emacs should be leading users, including those
new to Lisp, toward Lisp, not away from it.
And this is especially the case when it comes
to knowledge about a user option.  There's no
reason to hide the name of an option - quite
the contrary.

bug#400: [External] : Re: bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: Eli Zaretskii <eliz@gnu.org>, "400@debbugs.gnu.org" <400@debbugs.gnu.org>
> Date: Thu, 21 Oct 2021 04:26:19 +0000
> Accept-Language: en-US
> 
> > What about making the unlispified variable name into a button?  It
> > could offer to take you to *Help* or to *info*, for instance.
> 
> Please read what I wrote about that today.

Please assume that everyone does read and take note of what you wrote,
and try not to reiterate that time and again, because doing so just
increases the noise level without adding anything useful.

> The Lisp name should appear (always), whether
> the phony, non-Lisp "name" appears or not, and
> whether or not the name is a link ("button")
> to the real *Help*.

Yes, you already said that.

> Emacs should be leading users, including those
> new to Lisp, toward Lisp, not away from it.
> And this is especially the case when it comes
> to knowledge about a user option.  There's no
> reason to hide the name of an option - quite
> the contrary.

Yes, you already said that.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 20 Oct 2021 14:02:35 -0700
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 400@debbugs.gnu.org, drew.adams@oracle.com
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't see how using "C-h v" in that case is a reasonable use case,
> > since the documentation is displayed right below the name of the
> > option.
> >
> > We could perhaps have a help command that recognized names of
> > variables in this format, but then it shouldn't be "C-h v", IMO, since
> > that command talks about _variables_, whereas a name such as "Info
> > Hide Note References" is not a variable name.
> 
> I appreciate the merits of this point of view, but at the same time it
> would be kind of nice with some DWIM here.
> 
> I for one have gone through switching unlispify off, because it is
> faster to hit `C-h v RET' (firmly committed to muscle memory) than
> fiddling around with however it is you expand the documentation in a
> customize buffer; I guess the fastest way is C-a RET TAB TAB TAB (until
> point lands on "More") and then RET again.

??? The doc string is displayed by default, fully expanded.  So why
would you need to "expand" it?  What am I missing?

> So I think I would actually appreciate this feature, in particular if it
> was on `C-h v' because that's what I use everywhere else for variables.
> Even if it could perhaps be considered a bit "unclean".

Even if I'm missing something above, and you don't see the full doc
string by default, wouldn't it be better to have a special command in
the Custom buffer to expand the doc string, than tweak "C-h v" to do
something special in such cases?

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Howard Melman]

Eli Zaretskii <eliz@gnu.org> writes:

> ??? The doc string is displayed by default, fully expanded.  So why
> would you need to "expand" it?  What am I missing?

For me in Emacs 27 customize buffers default to showing only
the first line of the docstring for each variable and I
can't find a way to change this to show full docstrings.

Is this different in Emacs 28?  It seems the related
bug#15748 "Provide a way to hide/show all values" is still
open.

-- 

Howard

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Eli Zaretskii]

> From: Howard Melman <hmelman@gmail.com>
> Date: Thu, 21 Oct 2021 11:47:08 -0400
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > ??? The doc string is displayed by default, fully expanded.  So why
> > would you need to "expand" it?  What am I missing?
> 
> For me in Emacs 27 customize buffers default to showing only
> the first line of the docstring for each variable and I
> can't find a way to change this to show full docstrings.
> 
> Is this different in Emacs 28?

No, it's the same in both Emacs 27 and 28: the full doc string is
shown.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Howard Melman]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]


> On Oct 21, 2021, at 1:02 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> For me in Emacs 27 customize buffers default to showing only
>> the first line of the docstring for each variable and I
>> can't find a way to change this to show full docstrings.
>> 
>> Is this different in Emacs 28?
> 
> No, it's the same in both Emacs 27 and 28: the full doc string is
> shown.

That's not what I see via emacs -Q and doing M-x customize-group for apropos:



I have to click on "More" for each one.

Howard

[-- Attachment #2.1: Type: text/html, Size: 1195 bytes --]

[-- Attachment #2.2: Screen Shot 2021-10-21 at 10.34.41 PM.png --]
[-- Type: image/png, Size: 175985 bytes --]

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Eli Zaretskii]

> From: Howard Melman <hmelman@gmail.com>
> Date: Thu, 21 Oct 2021 22:36:21 -0400
> Cc: 400@debbugs.gnu.org
> 
> >> For me in Emacs 27 customize buffers default to showing only
> >> the first line of the docstring for each variable and I
> >> can't find a way to change this to show full docstrings.
> >> 
> >> Is this different in Emacs 28?
> > 
> > No, it's the same in both Emacs 27 and 28: the full doc string is
> > shown.
> 
> That's not what I see via emacs -Q and doing M-x customize-group for apropos:
                                                   ^^^^^^^^^^^^^^^
You never said before that you are using customize-group.  I use
customize-variable, where the doc string is shown in its full length.
As I wrote elsewhere in this discussion, it would be fine to expand
the doc string when you expand the variable in the groups buffer,
before you start customizing it.

> I have to click on "More" for each one.

Surely, not a big deal?

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Howard Melman]

Eli Zaretskii <eliz@gnu.org> writes:

> You never said before that you are using customize-group.

We'll you never said you were using customize-variable, just
customize :)   I didnt' realize they would be different.

>> I have to click on "More" for each one.
>
> Surely, not a big deal?

I never said it was "a big deal" I said "I can't find a way to
change this to show full docstrings".  Surely it's a
repetative task that emacs could do for me.

-- 

Howard

bug#400: [External] : bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

> I never said it was "a big deal" I said "I can't find a way to
> change this to show full docstrings".  Surely it's a
> repetative task that emacs could do for me.

Just as for discussing improvements to navigating among
Customize entries, this discussion of hiding/showing
the doc of entries is not part of this bug report.
Please take that (useful) discussion elsewhere.  Thx.

There are many ways that Customize could be improved,
no doubt.  This is not the place to start discussing
them.  This bug report is about having `C-h v', bound
to `describe-variable', pick up the option name when
at point.
___

As the option name, strictly speaking, might not be
shown at all, due to unlispifying, it makes sense
perhaps to discuss here the possibility of not
unlispifying by default, or not doing that at all,
ever.  I don't demand that that be considered part
of this bug thread, but I think it's strongly related.
I can file a separate bug for that, if someone objects
to considering that as part of this bug thread.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> ??? The doc string is displayed by default, fully expanded.  So why
> would you need to "expand" it?  What am I missing?

I believe it is fully expanded by default in `customize-option' but not
in `customize-group'.

>> So I think I would actually appreciate this feature, in particular if it
>> was on `C-h v' because that's what I use everywhere else for variables.
>> Even if it could perhaps be considered a bit "unclean".
>
> Even if I'm missing something above, and you don't see the full doc
> string by default, wouldn't it be better to have a special command in
> the Custom buffer to expand the doc string, than tweak "C-h v" to do
> something special in such cases?

A special command to expand would be useful, I think.

But users might still want an easy way to get the variable into the help
buffer.  For example, they might be using helpful.el that displays all
kinds of additional information in that buffer, or they might just
prefer having a separate buffer to display the documentation.  I'm in
the latter camp; expanding documentation on the customize screen itself
makes it harder to get an overview of all available options, so I often
would rather put the full length docstring in a separate buffer.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 21 Oct 2021 09:34:20 -0700
> Cc: larsi@gnus.org, 400@debbugs.gnu.org, drew.adams@oracle.com
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > ??? The doc string is displayed by default, fully expanded.  So why
> > would you need to "expand" it?  What am I missing?
> 
> I believe it is fully expanded by default in `customize-option' but not
> in `customize-group'.

Yes, because the actual customization happens in the variable's
buffer.  So why is that a problem, again?

> > Even if I'm missing something above, and you don't see the full doc
> > string by default, wouldn't it be better to have a special command in
> > the Custom buffer to expand the doc string, than tweak "C-h v" to do
> > something special in such cases?
> 
> A special command to expand would be useful, I think.

That would work well in the buffer where you customize a variable, but
in customize-group buffer, where there are many variables.

> But users might still want an easy way to get the variable into the help
> buffer.

They have RET and mouse-1 click, don't they?  Isn't that enough?

> For example, they might be using helpful.el that displays all
> kinds of additional information in that buffer, or they might just
> prefer having a separate buffer to display the documentation.  I'm in
> the latter camp; expanding documentation on the customize screen itself
> makes it harder to get an overview of all available options, so I often
> would rather put the full length docstring in a separate buffer.

I say we have enough features to allow anyone to do what they want,
and I see no reason to complicate commands for the marginal gains (if
at all) that you describe.

(Shouldn't there be some kind of "statute of limitations" on bugs that
were filed too long ago, and have not gathered enough consensus for
all that time?)

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, because the actual customization happens in the variable's
> buffer.  So why is that a problem, again?

No, you can customize it directly from `customize-group'.

>> But users might still want an easy way to get the variable into the help
>> buffer.
>
> They have RET and mouse-1 click, don't they?  Isn't that enough?

Where in the customize buffer do I click or type RET to get
`describe-variable'?

> I say we have enough features to allow anyone to do what they want,
> and I see no reason to complicate commands for the marginal gains (if
> at all) that you describe.

Well, it's a quality of life feature, so of course I'm okay without it.

But I'm not sure what you mean by "complicating commands" given that the
proposal AFAIU is to introduce a specific `customize-describe-variable'
bound to `C-h v' that handles also the unlispified names.

> (Shouldn't there be some kind of "statute of limitations" on bugs that
> were filed too long ago, and have not gathered enough consensus for
> all that time?)

I believe the activity we are engaged in right now is currently as good
as it gets.  FWIW, if I had my way, I would for sure close bugs and
feature requests far more enthusiastically than is being done now.

For example, "wontfix" could also be used meaning: "yes, it's an issue
but it's not one we consider worth fixing, if you care enough send a
patch and we will reconsider".

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 21 Oct 2021 10:50:34 -0700
> Cc: larsi@gnus.org, 400@debbugs.gnu.org, drew.adams@oracle.com
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Yes, because the actual customization happens in the variable's
> > buffer.  So why is that a problem, again?
> 
> No, you can customize it directly from `customize-group'.

When you do, I'm okay with fully expanding the doc string of the
variable which you are customizing from the groups buffer.  Would that
solve the issue at hand?

> >> But users might still want an easy way to get the variable into the help
> >> buffer.
> >
> > They have RET and mouse-1 click, don't they?  Isn't that enough?
> 
> Where in the customize buffer do I click or type RET to get
> `describe-variable'?

You get the full doc string by typing RET on the "More" button.

> > I say we have enough features to allow anyone to do what they want,
> > and I see no reason to complicate commands for the marginal gains (if
> > at all) that you describe.
> 
> Well, it's a quality of life feature, so of course I'm okay without it.
> 
> But I'm not sure what you mean by "complicating commands" given that the
> proposal AFAIU is to introduce a specific `customize-describe-variable'
> bound to `C-h v' that handles also the unlispified names.

How would you implement that without complicating the command?  The
unlispified name is just several English words.

Why do we need to make Emacs so much more complex for the benefit of
an obscure use case, which already has more than one existing
solution?

> > (Shouldn't there be some kind of "statute of limitations" on bugs that
> > were filed too long ago, and have not gathered enough consensus for
> > all that time?)
> 
> I believe the activity we are engaged in right now is currently as good
> as it gets.  FWIW, if I had my way, I would for sure close bugs and
> feature requests far more enthusiastically than is being done now.

Please do, then.  IMNSHO, a proposal for a minor feature that exists
for more than a decade, and was discussed at length without generating
any reasonable consensus, should be closed as wontfix.

> For example, "wontfix" could also be used meaning: "yes, it's an issue
> but it's not one we consider worth fixing, if you care enough send a
> patch and we will reconsider".

Exactly.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> No, you can customize it directly from `customize-group'.
>
> When you do, I'm okay with fully expanding the doc string of the
> variable which you are customizing from the groups buffer.  Would that
> solve the issue at hand?

I don't think I understand what this proposal means.  Could you perhaps
spell it out more explicitly?

>> But I'm not sure what you mean by "complicating commands" given that the
>> proposal AFAIU is to introduce a specific `customize-describe-variable'
>> bound to `C-h v' that handles also the unlispified names.
>
> How would you implement that without complicating the command?  The
> unlispified name is just several English words.

Maybe we are miscommunicating.  I mean that if we add a new command
`customize-describe-variable', it won't complicate `describe-variable'.

> Why do we need to make Emacs so much more complex for the benefit of
> an obscure use case, which already has more than one existing
> solution?

I just noticed that we already have such handling of unlispified names
in `C-h S', which is IMO a useful DWIM feature.  So this wouldn't be
that different.

>> I believe the activity we are engaged in right now is currently as good
>> as it gets.  FWIW, if I had my way, I would for sure close bugs and
>> feature requests far more enthusiastically than is being done now.
>
> Please do, then.  IMNSHO, a proposal for a minor feature that exists
> for more than a decade, and was discussed at length without generating
> any reasonable consensus, should be closed as wontfix.
>
>> For example, "wontfix" could also be used meaning: "yes, it's an issue
>> but it's not one we consider worth fixing, if you care enough send a
>> patch and we will reconsider".
>
> Exactly.

This message has been received; I'll try to apply it with the necessary
restraint.  I expect that you will let me know if I don't.  ;-)

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 21 Oct 2021 12:45:15 -0700
> Cc: larsi@gnus.org, 400@debbugs.gnu.org, drew.adams@oracle.com
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> No, you can customize it directly from `customize-group'.
> >
> > When you do, I'm okay with fully expanding the doc string of the
> > variable which you are customizing from the groups buffer.  Would that
> > solve the issue at hand?
> 
> I don't think I understand what this proposal means.  Could you perhaps
> spell it out more explicitly?

To customize a variable from the groups buffer, you click or type RET
on the arrow to expand its customization form, right?  However, the
doc string of the variable is still shown in its one-line variant.
I'm saying that showing the full doc string as result of that could be
a sufficient solution.

> >> But I'm not sure what you mean by "complicating commands" given that the
> >> proposal AFAIU is to introduce a specific `customize-describe-variable'
> >> bound to `C-h v' that handles also the unlispified names.
> >
> > How would you implement that without complicating the command?  The
> > unlispified name is just several English words.
> 
> Maybe we are miscommunicating.  I mean that if we add a new command
> `customize-describe-variable', it won't complicate `describe-variable'.

But then you usurp the "C-h v" key binding for another command, and
the user cannot invoke the original Help command easily?

> >> For example, "wontfix" could also be used meaning: "yes, it's an issue
> >> but it's not one we consider worth fixing, if you care enough send a
> >> patch and we will reconsider".
> >
> > Exactly.
> 
> This message has been received; I'll try to apply it with the necessary
> restraint.  I expect that you will let me know if I don't.  ;-)

Thanks, will certainly do (although I don't expect that to be needed
too much).

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> To customize a variable from the groups buffer, you click or type RET
> on the arrow to expand its customization form, right?  However, the
> doc string of the variable is still shown in its one-line variant.
> I'm saying that showing the full doc string as result of that could be
> a sufficient solution.

That could work, but if the docstring is long it might be considered
disruptive.

>> Maybe we are miscommunicating.  I mean that if we add a new command
>> `customize-describe-variable', it won't complicate `describe-variable'.
>
> But then you usurp the "C-h v" key binding for another command, and
> the user cannot invoke the original Help command easily?

That's true.  But if the only difference between the original command
and the new one is that the new one gives you a default, whereas tho old
one gives you no default, perhaps this is okay.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 22 Oct 2021 01:12:22 -0700
> Cc: larsi@gnus.org, 400@debbugs.gnu.org, drew.adams@oracle.com
> 
> >> Maybe we are miscommunicating.  I mean that if we add a new command
> >> `customize-describe-variable', it won't complicate `describe-variable'.
> >
> > But then you usurp the "C-h v" key binding for another command, and
> > the user cannot invoke the original Help command easily?
> 
> That's true.  But if the only difference between the original command
> and the new one is that the new one gives you a default, whereas tho old
> one gives you no default, perhaps this is okay.

Which means you _are_ going to extend describe-variable for that.  And
that is why I suggested to do that only for customize-variable,
because in such a buffer offering the variable being customized as the
default is a no-brainer.

bug#400: [External] : Re: bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

> > Maybe we are miscommunicating.  I mean that if we add a new command
> > `customize-describe-variable', it won't complicate `describe-
> > variable'.
> 
> But then you usurp the "C-h v" key binding for another command, and
> the user cannot invoke the original Help command easily?

Agreed.  `C-h v' should stay `describe-variable',
and its behavior should remain the same as always.

All that's needed is to provide the option name
as default value, when at point (not when the
cursor is on something else that makes sense as
a default).

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Howard Melman]

Stefan Kangas <stefan@marxist.se> writes:

> A special command to expand would be useful, I think.
>
> But users might still want an easy way to get the variable into the help
> buffer.  For example, they might be using helpful.el that displays all
> kinds of additional information in that buffer, or they might just
> prefer having a separate buffer to display the documentation.  I'm in
> the latter camp; expanding documentation on the customize screen itself
> makes it harder to get an overview of all available options, so I often
> would rather put the full length docstring in a separate buffer.

FWIW I'd like a command in a customize-group buffer to
expand all docstrings.  When I try out a new package I often
use customize-group to get an overview of things I can tweak
in it, and it's a pain to click More on all the options and
to open them.

bug#15748 "Provide a way to hide/show all values" is for
this, but I'm now thinking that something like outline-cycle
would be great in any customize buffer.  Let S-TAB cycle
through the various states of all options at once.

-- 

Howard

bug#400: [External] : bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

> FWIW I'd like a command in a customize-group buffer to
> expand all docstrings.  When I try out a new package I often
> use customize-group to get an overview of things I can tweak
> in it, and it's a pain to click More on all the options and
> to open them.
> 
> bug#15748 "Provide a way to hide/show all values" is for
> this, 

+1. Yes.

> but I'm now thinking that something like outline-cycle
> would be great in any customize buffer.  Let S-TAB cycle
> through the various states of all options at once.

Fine.  But:

1. There should also be a simple visual affordance
   (e.g., button or some indication of a key to hit).
   Customize is also (but not only) for new users,
   who won't necessarily know about such a cycling
   key.

2. Unfortunately, Emacs decided to follow the outside
   convention that S-TAB has the same behavior as TAB,
   except that it cycles backward.  This wasn't a good
   idea, IMO, but it was done, so another key would be
   needed for your cycling behavior.

bug#400: [External] : bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Juri Linkov]

>> but I'm now thinking that something like outline-cycle
>> would be great in any customize buffer.  Let S-TAB cycle
>> through the various states of all options at once.
>
> Fine.  But:
>
> 1. There should also be a simple visual affordance
>    (e.g., button or some indication of a key to hit).
>    Customize is also (but not only) for new users,
>    who won't necessarily know about such a cycling
>    key.

A help text at the beginning should be sufficient.

> 2. Unfortunately, Emacs decided to follow the outside
>    convention that S-TAB has the same behavior as TAB,
>    except that it cycles backward.  This wasn't a good
>    idea, IMO, but it was done, so another key would be
>    needed for your cycling behavior.

In outline-minor-mode, S-TAB cycles outlines only when point is
on the heading.  Otherwise, S-TAB preserves its original binding
to move backward.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

> > emacs -Q
> > M-x customize-option Info-hide-note-references
> >
> > Put the cursor on the unlispified option name:
> > Info Hide Note References.
> >
> > C-h v
> >
> > The option name is not picked up as the default value.
> 
> The command just calls variable-at-point, which doesn't have any
> machinery to go from the displayed data to the actual symbol (which
> info-look has).
> 
> It's trivial to fix (now after bug#41905 was fixed), but I'm not sure at
> what level to do that.  The least invasive way to do it would be to just
> redefine `C-h v' in Customize buffers, but the way `describe-variable'
> is defined would require a refactor of that function.
> 
> `variable-at-point' could grow some way to allow it to be parameterised,
> for instance via a buffer-local variable-at-point-function, which would
> be kinda clean and is how many similar things are handled...

My feeling, so far: keep it simple.

cus-edit.el should provide the inverse operation
to `custom-unlispify-tag-name', which would give
you the Lisp symbol name that corresponds to the
unlispified name.

If that inverse operation would not be trivial or
well-defined for some reason, for some cases (?),
then the code should just record the association
between the two names - IOW, memoize the result
of calling `custom-unlispify-tag-name', and
thereafter just use lookup, in either direction.

(I think we should anyway have such a two-way
conversion/lookup, regardless of this bug.)

Then, `variable-at-point' would just call that
inverse operation (a lookup) when the mode is
`Custom-mode' and `custom-unlispify-tag-names'
is non-nil.

I don't think we should redefine "`C-h v' in
Customize buffers".  And I don't think we need to
provide parameterization for `variable-at-point'.
Not just for this, anyway.

I also don't favor a `display' property approach
here, a priori.  I think it's overkill here and
can restrict other possibilities/behavior.  (Even
just wanting to copy the "friendly" name of the
option, to paste it somewhere.)

A `display' property can be handy, but it can
really mess with things too - kinda like wrapping
duct tape around things: fixes them but makes
them unmovable and difficult to interact/work with.

But my opinion could change, based on other
arguments.

bug#400: 23.0.60; C-h v should pick up lispified name in Customize

[Drew Adams]

> > > emacs -Q
> > > M-x customize-option Info-hide-note-references
> > >
> > > Put the cursor on the unlispified option name:
> > > Info Hide Note References.
> > >
> > > C-h v
> > >
> > > The option name is not picked up as the default value.
> 
> I don't see how using "C-h v" in that case is a reasonable use case,
> since the documentation is displayed right below the name of the
> option.
> 
> We could perhaps have a help command that recognized names of
> variables in this format, but then it shouldn't be "C-h v", IMO, since
> that command talks about _variables_, whereas a name such as "Info
> Hide Note References" is not a variable name.

I said, "picked up as the default value".  Yes,
of course the unlispified name is typically not
itself a variable name.  But it's reasonable in
this context to provide the Lisp variable name
as a default value here, for `C-h v'.

As Kevin pointed out, `C-h v' provides not only
the doc string but links.

And this bug report is really more general, in
the sense that if we give Customize the inverse
function (get the Lisp name from the unlispified
name) then that can be used for more than just
`C-h v' - `describe-face', for instance.

The fact that `C-h v' output/behavior is similar
to what `customize-option' shows shouldn't get
in the way of seeing the utility of providing
a way to get the Lisp name from the unlispified
name.  That can be used beyond `C-h v'.