RE: Getting more info on a variable in Customize buffers

[Drew Adams]

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

I won't argue about how it should be done - I'm no authority, and I don't
really care how it is done - whether this (and the other custom-* variables
perhaps) gets autoloaded or it is preloaded along with its library
`cus-edit.el', or whatever.

The point is that the existence of custom-* variables should somehow be
brought to the attention of Customize users.

In fact, that is perhaps another, general problem: how to know how to
customize Customize. Unless users know of the particular user options that
change the behavior of Customize, they can't customize that behavior. To
find this particular option, they need to browse down through custom group
Help, then group Customize, to group Custom Buffer, then open each of the
twenty or so options in that group individually, and read their descriptions
to find that there is one that controls name display. And that assumes that
they don't get sidetracked by the other four Custom groups and their own
myriads of options. Such discovery is fun, indeed.

And Info is little help in this regard - it tells you a few things about how
to use Customize, but I don't think it says anything about the various
custom groups and customizing Customize itself (which is part of using it,
as the unlispify example points out). Perhaps Customize needs its own Info
(an embarassing need, perhaps, but so be it)? Or perhaps it just needs some
UI improvement, to make some of this stuff more obvious, more immediate.

(BTW, if I click the "Parent documentation: Manual" button at any of the
Customize buffers for Customize itself, I get the Info node about using Lisp
to write customization definitions - not what a user expects here, perhaps.)

Anyway, I agree that it is better if users need not worry about the actual
variables involved. That's why I proposed letting them discover that
clicking the user-option name would toggle its own display form, and a
message would inform them that the display form is controlled globally by
user option "Custom Unlispify Tag Names" (`custom-unlispify-tag-names').

(BTW2: Prettifying names like `custom-unlispify-tag-names' in this way does
_not_ make them more understandable or more readable. If we want a
user-friendly "pretty" name, then that name needs to be obtained otherwise.
Perhaps a :pretty-name keyword similar to :help?)

    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.

This variable has probably been _known_ by extremely few people. Echoes of
the French foreign minister in the 80s who said of the New Caledonia
independentistes: "Since we stopped listening to them, we don't hear
anything from them." Just because you don't get complaints doesn't mean that
Customize is fine as it is. Perhaps some of those who might use it more have
tried it and given up.

BTW3: I happen to write all of my .emacs by hand. So what? I still need
(want) to be able to make sense of the Customize jungle. If nothing else, I
would hope that it would serve as an options browser (like `edit-options').
And if Customize were a little more user friendly, I might start using it
more.

Someday, I would like to be able to get to the proper Customize location
from things like apropos or Info or source code - to somehow search and
_find_ "Custom Unlispify Tag Names" (`custom-unlispify-tag-names').
Idealistic?

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

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

You hinted at a different-variables problem above. I take your word for it.

    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.

OK. So for 99% of the cases, where it tells you the truth and there is no
difference between the two variables, it should work. And clicking the name
to toggle the display type should work. I could live with that.

For the corner cases, clicking the name to change its display can echo a
message, "Sorry, this is an indescribable Emacs oddity, er, design feature.
Have a nice day." I could live with that too. No problem.

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

If there is no problem with the click-name-to-change-its display proposal,
then let's go for it. If there is a problem with it for the corner cases,
then let's help the user when she clicks the name by telling her not to
bother trying to understand (see error message above).

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

    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.

Emacs has long been about "looking underneath" - so much so that, unlike
other editors/languages/tools/environments, it's not even considered
"looking underneath". It's nothing to be ashamed of, and nothing to be
reserved for a nerd elite. We are all more or less nerdy, some of us more,
some of us less. You don't _have_ to look underneath, but Emacs doesn't put
obstacles in the way of your looking underneath.

Saying "if you use Custom to customize Emacs, then you shouldn't need to
care about variable names" is wrong. Or perhaps "not need" is technically
correct, but the point is "want", not "need". Customize is a user-variable
browser and editing tool. It should be useful for all Emacs users, not just
those who forsake Lisp and .emacs.

IOW, I reject the idea that there should be two hermetically separate worlds
of Emacs users: the Customize crowd and the Lisp lot.

And Customize already sends you to plenty of Lispian literature, so it is
apparently not part of the _design_ that it keep you from Lisping. See the
Manual button I mentioned above, for instance: If we assume that Customize
users are to shun Lisp, then why send them to the Lisp manual for info on
how to code customize groups and such?

And, as I said, since Info, apropos, source code, and *Help* all use Lisp
variable names and sexps, Customize should play well with those too. It
should even enhance the use of those tools - that is, it should play _very_
well with them (and vice versa).

If the Customize design doesn't agree with your two-worlds view, then the
problem about getting values and variable names as Lisp sexps is a UI bug
("opportunity for improvement"), not a design feature.

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

I am satisfied with `custom-unlispify-tag-names' - I just wasn't aware of
it. I like it so much now that I want other users to know about it. I'm
interested in our improving Customize - that's all. I haven't given up on it
yet.

And to come back to the thread beginning: Customize buffers should be able
to display the _current value of a variable as a sexp_, as does `C-h v'.
That request seems to have gotten lost in the discussion about
`custom-unlispify-tag-names'.

 - Drew