bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#400: 23.0.60; C-h v should pick up lispified name in Customize
Date: Thu, 21 Oct 2021 20:09:03 +0300

> 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?)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]