Re: Getting more info on a variable in Customize buffers

[Stefan Monnier]

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

Autoloading a variable should only be done if it's necessary for correctness
(typically because the default value is not nil and the user is likely to
want to do something like `add-to-list' on it in her .emacs).

This variable has been used by extremely few people.  Extremely few people
have complained about the varname-vs-prettyname difference.  Most/all of
those who complained write 90% of their .emacs file by hand anyway.

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

The designer might call it a feature rather than a problem.

I do tend to think that it was a mistake to design something that looks like
an elisp variable and which happens to be an elisp variable in 99% of the
cases but which may be something else.

> Anyway, if this is a problem for the unusual cases, then how is possible to
> have option `custom-unlispify-tag-names' work for them?

It works, but it may not always tell you the truth.  Because the truth is
that a custom-var called "foo-bar" might not have *any* real variable
corresponding to it (not even "toto").  E.g. setting "foo-bar" to ON may
just add something to foo-mode-hook and setting it to OFF removes it from
the hook.  Retrieving the value of "foo-bar" is done by looking at the
foo-mode-hook.

> If there is a problem with corner cases, then that problem must already
> manifest itself with `custom-unlispify-tag-names', no?

Of course not.  The problem is in how the user interprets what she sees, not
in the code.

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

I'm not sure who are those mythical "Emacs priests".  Of course you can use
Custom to customize Emacs, but if you do that you shouldn't need to care
about variable names.  If you care about actual variable names, it's either
because you're looking underneath Custom (in which case you're dealing with
Elisp and might as well write your .emacs by hand as mentioned before), or
because there's a problem with Custom.

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

I never suggested to remove custom-unlispify-tag-names.  If that's what you
prefer, use it.  But you don't seem satisfied with it.
Note that to a large extent I agree with you that it should be nil
by default.


        Stefan