RE: Getting more info on a variable in Customize buffers

[Drew Adams]

    > - You need to load `cus-edit.el' to see this variable (not a
    >   great problem, but it would be good to have it autoloaded).

    Most variables are only visible once the corresponding package
    is loaded. That's normal.

It may be normal for most variables, but I think this one merits an
autoload.

It sounds from this thread as if the decision to prettify names by default
in Customize is not too solidly supported anyway, and that many users might
prefer the Lisp names. If users who potentially would prefer Lisp names
don't even know that displaying Lisp names is an option, then that is a
loss.

There are plenty of `custom-*' variables whose doc strings are available on
startup of Emacs - this should be one of them.

    > What about 1) having click-a-name-to-toggle-its-display-type, as I
just
    > mentioned, and 2) display a message in the echo area when you do this,
    > saying that you can use `custom-unlispify-tag-names' to set the custom
    > display type globally. Finding this (oddly named) option would then be
    > fairly easy and common.

    The problem is that custom's "variables" aren't the same as
    Elisp variables.  They look very much alike, and they usually
    are exactly the same, but that's not always the case.
    The :get, :set, and :init thingies allow you to define a custom setting
    "foo-bar" which controls "toto" rather than the variable "foo-bar".

I probably don't fully understand, although I think I follow you. Sounds
like an implementation problem to me - or perhaps a design problem?

So, what about the "usual" case? (90%? 99%? 99.999%? 80%? 60%? 51%? - what
does "usually" mean here?) Why couldn't/shouldn't this be implemented for
the _usual_ case, and not worry about the corner cases?

Anyway, if this is a problem for the unusual cases, then how is possible to
have option `custom-unlispify-tag-names' work for them? If there is a
problem with corner cases, then that problem must already manifest itself
with `custom-unlispify-tag-names', no?

If you can get the desired effect by turning off
`custom-unlispify-tag-names', then why can't you turn it off locally by
clicking the "pretty" name? What's the obstacle, here?

    If you care about the variable names, I recommend you just skip custom
    altogether and write elisp code in your .emacs.  It'll be
    cleaner and easier to understand.

That sounds ridiculous to me (but perhaps I misunderstand you). Emacs
priests have been preaching that Customize is _The Way_ for quite some time
now. Most of the standard Emacs code now uses Customize for user variables.
To understand and modify the standard Emacs variables, we are naturally led
to Customize.

And you're now telling us that if I we don't like something about the
Customize UI we should just skip it? Instead of letting Customize show the
same thing (as an option!) that `C-h v' shows, we should just forget it? Why
not get rid of `C-h v', or prettify its names too, while you're at it?

If the Customize UI is not enough user-friendly or presents obstacles to
navigating the available information, the answer is not to send users
packing, to tell them to just use `setq's in their .emacs.

I "care about variable names" because that's what I need to care about in
order to use Emacs well. If the code and the doc strings and the Info doc
and Apropos and... all used the Customize "pretty" names - if none of _them_
"cared about variable names" - then no, I wouldn't care much about variable
names either. Sheesh!  (Quand les poules auront des dents...)