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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: larsi <at> gnus.org, 400 <at> debbugs.gnu.org, drew.adams <at> oracle.com
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 <at> marxist.se>
> Date: Thu, 21 Oct 2021 09:34:20 -0700
> Cc: larsi <at> gnus.org, 400 <at> debbugs.gnu.org, drew.adams <at> oracle.com
> 
> Eli Zaretskii <eliz <at> 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?)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.