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

[Eli Zaretskii <eliz@gnu.org>]

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