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

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

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

[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

[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

[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

[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

[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

[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: 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

[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

[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: 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: 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