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

[Drew Adams <drew.adams@oracle.com>]

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