emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Getting more info on a variable in Customize buffers


From: Drew Adams
Subject: RE: Getting more info on a variable in Customize buffers
Date: Sun, 2 Jan 2005 11:48:26 -0800

I hesitated whether to send my message to emacs-devel as a suggestion or to
help-gnu-emacs as a question. Perhaps I should have done the latter, as some
of the "problems" I mentioned were user error. Mea culpa.

However, maybe there is a lesson or two for emacs-devel anyway, in that at
least this user couldn't seem to find this info. And I still think that some
of the info is not there to be found.

    I personally agree that it would be better not to prettify variable
    names in Custom, but this probably has been discussed before.  You can
    get the variable name by first clicking on "Show Value", then on
    "State" and then selecting "Show initial Lisp expression".

Thanks.

However, that seems to show the _initial expression_ (written in the code),
which is not the same as the current value of the variable. I still don't
see any way to obtain the current value as a sexp, without using `C-h v'.

I assume that the initial Lisp expression is available here to give users an
idea of how to code an expression leading to a value. But customizing is
about changing the current value, so that current value should also be
available (in sexp form).

Also, another State menu item, "Don't show as Lisp expression", seems to be
presented as the converse of "Show Initial...", but it shows the current
value (in pretty form), not the initial expression. If these are supposed to
be opposites (as suggested by their complementary enablement), then
shouldn't they both be about initial expression or both be about current
value?

"Don't show..." doesn't just hide the Lisp expression; it also shows the
current value. And the word "as" in its name suggests that it shows the
value not "as" a Lisp expression, which suggests that Show Initial Lisp
Expression does show the _value_ as a sexp, which is incorrect.

This is confusing, to me.

If we make both the initial Lisp expression and the current value available
as sexps alternately in the same display field, then the menu items should
reflect that: Show Initial Lisp Expression, Show Value as Lisp, Show Value
as Text, or some such; and each menu item should only be disabled when its
action is a no-op (when what it shows is already shown).

I guess that no-op disabling is what happens now, but 1) Show Value as Lisp
is missing, and 2) Show Value as Text is called "Don't Show as Lisp
Expression", and this, together with 3) the complementary enablement,
misleads me into thinking that "Don't Show as..." is somehow the converse of
Show Initial Lisp Expression".

In any case, perhaps State is the wrong menu for this "show" stuff, IMO. I
expect to find menu items for _changing_ (setting) the state there (the
tooltip says "Change the state of this item"). Neither of these menu items
changes the state (value) of the variable or even the state of the
variable's setting wrt Emacs sessions.

I don't expect to see items for _showing_ the variable's defining expression
or its current value in the (change-) State menu. Why don't we move these
show/don't-show items to the Show Value menu (whose tooltip says "Show the
value of this item", which is closer to what "Show initial Lisp expression"
and "Don't show as Lisp expression" do? And change "Show Value" back to
"Show", as it was in Emacs 20 (since the initial Lisp expression is not the
variable value, but an expression that yields a value).

That way, we would have one menu (State) for changing the variable's session
state and another menu (Show) for changing its Customize display state. (And
Hide would then be inappropriate, obviously.) If we did that, then State
would be better named Change.

However, the State button is not so much about changing the variable value
(the Value Menu and the input text fields are for that) as it is about
_saving_ the new value for the current session or future sessions. The State
button would be best named "Setting", which indicates both 1) the act of
setting/resetting and 2) actions concerning the current setting. And the
presence of "Setting" will serve as a hint that changing the value is not
enough: it needs to be set.

BTW, all "buttons" that are actually menus should somehow look different
from the action buttons that immediately do something. Links to other
locations should look like links (e.g. underlined), as discussed previously;
action buttons should look (as now) like buttons that you press for an
immediate action; and menus should look different from both. A common
appearance for menus that are not in a menu bar is an icon or text button
with a tiny down-pointing triangle: "Show v".

Finally, why tie up the action to show the real (Lisp) variable _name_ with
the action to show the Lisp _value_ or the initial expression? Someone
looking for the variable name will not necessarily think to look for the
Lisp value or the initial sexp in order to find the name.

I'd suggest that display of real (Lisp) names vs pretty names be a user
option (variable), so that it is possible to globally display all names in
either way (so you can, say, search the Customize buffer). Also, clicking
either name could toggle that individual name to the opposite name display
(Lisp <--> pretty).

And I repeat my suggestion for Expand All (or Show All) for the information
in the More buttons (so you can search all doc strings for the group).

          2) a link to the variable definition in the source code

    If you need to read the source code to customize a variable, then
    there is a really bad problem with the docstring. Somebody wanting to
    study source code is going to do C-h v.

Why should one need to do `C-h v'? Customize does everything else that `C-h
v' does, so why not let it also get you to the code?

I disagree that doc strings should or could provide all of the info provided
by the source code - they will never do that. And these are not necessarily
two different groups of "somebodys": many (most?) users consult both doc and
code sometimes - they are complementary information sources.

And the question is not just whether you _need_ to consult the source code
to be able to _customize_ a variable - Customize is not just for changing
things (customizing); it is also an options and options-groups _browser_
(remember `edit-options'?). Even if a doc string is perfect, I might want to
consult the code - and I doubt that I am alone in that.

If we do decide to provide a link to the code as we do in `C-h v', then the
need to show the initial Lisp expression in the Customize buffer disappears
or is diminished. Showing the current value is much more important (to me),
anyway, than showing the initial Lisp sexp.

          3) a button to display the Lisp value of the variable (Hide/
         Show/Show Lisp would do the trick).

    Can be done as explained under 1).  In this case, the pretty form is
    sometimes more helpful to the user than the actual Lisp value.

Each is useful, for different needs. Again, the current Lisp value (not just
the initial expression) should be available, and the menu item is in the
wrong menu, IMO.

          4) perhaps a link to the variable's explanation in Info
         (when appropriate)

    The person writing the defcustom can already make such a link.
    (Using the :link keyword.)

Thanks; I wasn't aware of that. Yes, that's the right way to handle this.

        - To the Customize buffer for an individual variable only, we add:
          1) everything listed above for the Customize group buffer
          2) a link to the Customize group buffer

    There already is such a link. It says: Parent groups:
    Ediff Hook where "Ediff Hook" is a link you can follow.

Apologies. I was looking for those parent-group buttons in the same position
as in the other Customize buffers; the parent-groups links in this case are
at the buffer bottom, not the top. That little inconsistency threw me off.
There is a lot to read/scan in a Customize buffer. I looked all over for
those links, but somehow I didn't see them (old eyes).

It's important to keep things the same in the different Customize buffers,
whenever possible, so users can find things easily without needing to reread
the same boilerplate text they've already read in the other buffers. I'd
suggest moving these links to their usual place (near buffer top), unless
there is some good reason not to.

And I see now why we can't just drop the individual-variable Customize
buffer and send the user instead to the group Customize buffer (to provide
context): a variable can belong to more than one group.

Thanks,

  Drew





reply via email to

[Prev in Thread] Current Thread [Next in Thread]