Getting more info on a variable in Customize buffers

Getting more info on a variable in Customize buffers

[Drew Adams]

Customize is the preferred way to alter user variables. It also provides
information about user variables. But it seems to me that it is in some ways
less helpful than `C-h v'.

If I do `C-h v ediff-before-setup-windows-hook', the *Help* buffer gives me,
in addition to the variable's value and the doc string: 1) a link to
Customize the variable and 2) a link to the source code. And I can search on
the variable name in Info and in the source code to learn more about the
variable.

However:

1) If I click Customize in the *Help* buffer from `C-h v', I arrive at a
Customize buffer for only that variable, where there is no link to the
custom group of the variable, so I can't see how it might be related to
other variables in the group. It might be that what I really need is a
similarly named variable, but I can't browse the group to find it. In fact,
I can't even see what custom group the variable belongs to (no group name is
indicated).

2) If I somehow get to the Customize group (ediff-hook) to customize the
same variable, without coming from the `C-h v' *Help* buffer:

2a) The variable name does not appear as such. Instead, the name is
prettified using title-case and replacing dashes with spaces. A variable
with a mixed-case name like `Info-enable-edit' is indistiguishable in this
format from one that is all lowercase. There is nothing that indicates to a
user what the real name of the variable is and that the displayed name is a
transformation of the real name.

This is important because it is the real variable name that is the user's
link to more information; the title-case headline name is, at best, just a
pretty face. It is only with the real variable name that you can use apropos
or search the Info doc or the source code or even the rest of the Customize
buffer (for references from other doc strings). It is the real variable name
that serves everywhere to refer to the variable. If you understand that
there _is_ a variable named similarly to the pretty title (already not that
obvious), and you understand the name transformation (again, not that
obvious), then you can search for more information on the variable. But you
can't use `C-s C-w' to grab the name for searching, and you can't use `C-h
v' with the cursor on the pretty name to pick up the real name.

For me, it would be more useful to show the real variable name than the
title-case headline-style pretty name.

2b) There is no link to the source code that defines the variable. You need
to derive the real variable name from the pretty name and type that into
`C-h v', just to get a link to the source code. Getting to the definition of
a variable or function is one of the great strengths of Emacs over other
programs. Doc strings are great, but they don't always substitute for
looking at the real definitions. In Emacs, there is a progression from doc
to code, and the two reinforce each other. Lack of a link to the defining
code is an obstacle to that reinforcement.

2c) The variable value does not appear in its Lisp form. In some cases, it
is possible to see the Lisp form, but in other cases it cannot be seen.
Since many Emacs users also program Emacs Lisp, it would be good to provide
a link (button) that displays the Lisp value, exactly as shown in `C-v'.
Yes, Customize was designed so you don't have to be a Lisp programmer, but
it wouldn't hurt to make Lisp info available on demand.


All of this means that you are handicapped using Customize: you have less
information accessible to help you understand a variable and its relations
to commands and other variables. Customize should provide more information
than `C-h v', not less, even if that info is revealed only on demand.

The variable name is the most important piece of info in the Customize
buffer. With it, you can obtain most of the other info displayed there (`C-h
v'). If there is one thing the Customize buffer should show clearly,
literally, it's the variable name.

So, I suggest:

 - To the Customize buffer for a group containing a variable, we add:
   1) the real variable name, in such a way that it can be copied
      for pasting and searching and picked up by variable-at-point
   2) a link to the variable definition in the source code
   3) a button to display the Lisp value of the variable (Hide/
      Show/Show Lisp would do the trick).
   4) perhaps a link to the variable's explanation in Info
      (when appropriate)

   These could all be hidden under the More button, but it would be
   better if the variable name were not hidden, so it can be the
   target of a search. Alternatively, if the real name were hidden
   under More, we could add a single button to expand all the More
   buttons, to enable search across all the More information. Expand
   All for values might also be useful (though less so), for the same
   reason.

 - 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

Alternatively, we could eliminate the Customize buffer for an individual
variable altogether. Clicking the Customize link in *Help* would instead
take you to the correct entry in the Customize group buffer. That would have
the advantage of providing more context and related information.

Re: Getting more info on a variable in Customize buffers

[Luc Teirlinck]

Drew Adams wrote (taking ediff-before-setup-windows-hook as example):

   So, I suggest:

    - To the Customize buffer for a group containing a variable, we add:
      1) the real variable name, in such a way that it can be copied
	 for pasting and searching and picked up by variable-at-point

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

      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.

      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.

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

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

Sincerely,

Luc.

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

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

Re: Getting more info on a variable in Customize buffers

[Luc Teirlinck]

Drew Adams wrote (talking about "Show initial Lisp expression " in Custom):

   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 did not look at the source code, but from experimentation, it
appears that the _saved_ value is shown.  (Or the default value if
there is no saved value.)  A value set for the current session only is
ignored.  I do not know the motivation for this behavior.  I never
noticed, because I seldom use Custom to set something for the current
session only.

As Reiner pointed out, I forgot about `custom-unlispify-tag-names'.

Sincerely,

Luc.

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

       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 did not look at the source code, but from experimentation, it
    appears that the _saved_ value is shown.  (Or the default value if
    there is no saved value.)  A value set for the current session only is
    ignored.  I do not know the motivation for this behavior.  I never
    noticed, because I seldom use Custom to set something for the current
    session only.

So, it sounds like perhaps we should reconsider what the aim of this
so-called "initial Lisp expression" is. What is the need that its display is
meant to satisfy?

Is it supposed to show the defining _expression_ that yields the initial
value (what its name suggests)? Is it supposed to show the (sexp-form of)
the last saved value, as you say it does? Is it supposed to show the
currently set (but perhaps not saved) value as a sexp?

To me, the last of these is the most useful - it is what `C-h v' shows. I
can get the initial defining expression from the source code. And I'm not
very interested in knowing the last saved value (I can get it from .emacs or
custom-file, if I need it).

Once we decide what this is for, or what it should be for, we can pick a
good menu-item name for it.

Other opinions? Or are we misunderstanding what this is about?

 - Drew

Re: Getting more info on a variable in Customize buffers

[Robert J. Chassell]

"Drew Adams" <drew.adams@oracle.com> wrote, 

    So, it sounds like perhaps we should reconsider what the aim of
    this so-called "initial Lisp expression" is.  What is the need
    that its display is meant to satisfy?

The "initial Lisp expression" is supposed to be the default as
provided by the distribution.  This is what you get when you start
Emacs with `emacs -Q'.

Another Lisp expression is the previous value as set by a user in his
.emacs file (or, for people who have not yet learned Emacs Lisp, set
with `customize').

People who use .emacs for customization will be able to see a previous
value since either it will be visible in their .emacs file (or in a
backup) or it will be the `emacs -Q' default.

People who do not use .emacs should also be able to see a previous
value that is not a default (or, better yet, see several values, which
gives them more or less the equivalent of several different .emacs
files).

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

    The "initial Lisp expression" is supposed to be the default as
    provided by the distribution.  This is what you get when you start
    Emacs with `emacs -Q'.

Access to the current value, as in `C-h v', is more useful, if we have to
choose between the two.

If we want to have the installed ("emacs -Q") value in addition to the
current value, then:

1. It shouldn't be called "initial Lisp expression" if it is in fact the
value obtained by evaluating the initial Lisp expression. It should be
called something like "installed value".

2. More useful than just seeing the installed value would be an action to
_reset_ the variable to the installed value.

There's not much use in just _showing_ any value other than the current
value; and that can in fact lead to confusion, since one expects that the
value shown by "Show Value" is the current value of the variable (though
perhaps in a different format).

Re: Getting more info on a variable in Customize buffers

[Luc Teirlinck]

Drew Adams wrote:

   2. More useful than just seeing the installed value would be an action to
   _reset_ the variable to the installed value.

Clicking on "State" and choosing "Erase Customization" does exactly that.

Sincerely,

Luc.

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

       2. More useful than just seeing the installed value would be
          an action to _reset_ the variable to the installed value.

    Clicking on "State" and choosing "Erase Customization" does
    exactly that.

Great. Then the only value I can see in showing the installed value is to
let you know what you'll get if you Erase Customization. That could be done
by showing the new value and asking for confirmation when you click Erase
Customization.

And, since Erase Customization only applies to the current variable, it
should be called something like Reset Value, or Reset to Installed Value.
The current name can give the impression that it erases all customization.

Re: Getting more info on a variable in Customize buffers

[Per Abrahamsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> And, since Erase Customization only applies to the current variable, it
> should be called something like Reset Value, or Reset to Installed Value.
> The current name can give the impression that it erases all customization.

It used to be called "reset to standard setting", but somebody got
surprised that it actually deleted the variable from custom-file.  He
only expected it to change the value for the current session.  So it
got a new name.

Re: Getting more info on a variable in Customize buffers

[Per Abrahamsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> So, it sounds like perhaps we should reconsider what the aim of this
> so-called "initial Lisp expression" is. What is the need that its display is
> meant to satisfy?

The idea is to allow the user to edit the *unevaluated* expression
that is used to initialize the variable at start-up.  For example

(defcustom foo (if window-system 'x 2) 
  "doc"
  :type 'sexp)

Here, "show initial Lisp expression" will show 

   (if window-system 'x 2)

You can then edit and save that value.  

Maybe "show Lisp expression used for start up" would be better.

Or maybe just remove it, I have never heard of anyone who ever used
this feature.

Re: Getting more info on a variable in Customize buffers

[Miles Bader]

> Or maybe just remove it, I have never heard of anyone who ever used
> this feature.

I've used it; sometimes a custom definition is so fucked up that
looking at the lisp expr provides a useful clue what's going on.

[Why would anybody tell you if they used it anyway?]

-Miles

Re: Getting more info on a variable in Customize buffers

[Per Abrahamsen]

Miles Bader <snogglethorpe@gmail.com> writes:

>> Or maybe just remove it, I have never heard of anyone who ever used
>> this feature.
>
> I've used it; sometimes a custom definition is so fucked up that
> looking at the lisp expr provides a useful clue what's going on.

I didn't mean as a debugging aid.  I meant for adding code that will be
evaluated by initialization time.

> [Why would anybody tell you if they used it anyway?]

They would tell others:  "You can solve that problem by using this
neat feature".

Re: Getting more info on a variable in Customize buffers

[Luc Teirlinck]

Per Abrahamsen wrote:

   > So, it sounds like perhaps we should reconsider what the aim of this
   > so-called "initial Lisp expression" is. What is the need that its display is
   > meant to satisfy?

   The idea is to allow the user to edit the *unevaluated* expression
   that is used to initialize the variable at start-up.  For example

   (defcustom foo (if window-system 'x 2) 
     "doc"
     :type 'sexp)

   Here, "show initial Lisp expression" will show 

      (if window-system 'x 2)

   You can then edit and save that value.  

That is apparently not what it does.  If you set, say,
auto-revert-interval, which is 5 by default, to 10 and save for
future sessions, then set it to 20 for this session only, "show
initial Lisp expression" will show 10, not 5.

Sincerely,

Luc.

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

       > So, it sounds like perhaps we should reconsider what
       > the aim of this
       > so-called "initial Lisp expression" is. What is the
       > need that its display is meant to satisfy?

       The idea is to allow the user to edit the *unevaluated* expression
       that is used to initialize the variable at start-up.

    That is apparently not what it does.  If you set, say,
    auto-revert-interval, which is 5 by default, to 10 and save for
    future sessions, then set it to 20 for this session only, "show
    initial Lisp expression" will show 10, not 5.

I think you mean "will show 10, not (if window-system 'x 2)".

IOW, if this was supposed to show the unevaluated defining Lisp EXPRESSION
at installment, then you are saying that it doesn't - it shows the
last-saved VALUE (as a sexp). Two differences here: 1) when it was defined
(installment vs last save), 2) uneval'd vs eval'd.

It is most useful to see:

1) The current defining Lisp sexp (not necessarily the definition at
installment time, since another library might have modified the def). The
best way to make this available is with a link to the source code - a la
`C-h v'.

2) The current value of the variable as a sexp - a la `C-h v'. This is not
the same as the last-saved value. (The last-saved value is available in the
custom file/.emacs.)

Neither of these is currently available. The "initial Lisp expression"
should be dropped in favor of these two display options.

Re: Getting more info on a variable in Customize buffers

[Luc Teirlinck]

Drew Adams wrote:

       That is apparently not what it does.  If you set, say,
       auto-revert-interval, which is 5 by default, to 10 and save for
       future sessions, then set it to 20 for this session only, "show
       initial Lisp expression" will show 10, not 5.

   I think you mean "will show 10, not (if window-system 'x 2)".

No, I was talking about auto-revert-interval, which is an actual
option you can experiment with.  The defcustom gives it value 5, which
is a Lisp expression, an integer.

Sincerely,

Luc.

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

           That is apparently not what it does.  If you set, say,
           auto-revert-interval, which is 5 by default, to 10 and save for
           future sessions, then set it to 20 for this session only, "show
           initial Lisp expression" will show 10, not 5.

       I think you mean "will show 10, not (if window-system 'x 2)".

    No, I was talking about auto-revert-interval, which is an actual
    option you can experiment with.  The defcustom gives it value 5, which
    is a Lisp expression, an integer.

Right. Sorry.

But that example doesn't demonstrate the difference between uneval'd
expression and eval'd value (because 5 evaluates to 5). (It does demonstrate
that it is the last-saved value or expression that is displayed.)

I just tried the example that Per gave:

 (defcustom foo (if window-system 'x 2)
     "doc"
     :type 'sexp)

Using Customize, I did "show initial Lisp expression", to see (if
window-system 'x 2). I changed that sexp to (if window-system 'y 5) and did
"set for current session".

I clicked "don't show as Lisp expression", then "show initial Lisp" and it
showed (if window-system 'x 2). So, turning off, then on again, the "show
initial Lisp" changed the displayed value back to what it was before the
value was changed. The current value (via "don't show" again) always
reflects the lates value, of course.

I changed the Lisp expression again, but this time did "save for future
sessions". Clicking "don't show" followed by "show initial" then showed the
new Lisp expression, (if window-system 'y 5).

Summary: "Show initial Lisp expression" shows the uneval'd Lisp expression
(not value) that was last saved. It doesn't show the last Lisp expression
used to set the variable (unless the value was saved).

Perhaps there is some good in putting together the display of the last
defining sexp used in Customize with the defining library source code. A
single menu item, "Show Lisp definition" could display the last-defining
code, whether it is in the user's custom file (.emacs) or the last-defining
Lisp library. Opinions?

I think that there should be a menu item that takes you to the last-defining
Lisp-library definition, regardless of whether or not there is a later
definition in your .emacs. The library source code is more informative than
a simple sexp. However, there is a risk that the user will get confused,
because in that case the source library code did not actually define the
latest value. Are both needed?

In any case:

- A link to the library source code is needed, as in `C-h v'.
- If the defining Lisp sexp in the custom file is also
  shown (or linked), then the same should be done for `C-h v'.
- The current _value_ should also be displayable as a sexp,
  as in `C-h v'.

Re: Getting more info on a variable in Customize buffers

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> If you set, say, auto-revert-interval, which is 5 by default, to 10
> and save for future sessions, then set it to 20 for this session
> only, "show initial Lisp expression" will show 10, not 5.

If the standard value is 5, the saved value is 10, and the current
value is 20, then "the *unevaluated* expression that is used to
initialize the variable at start-up" is 10.

The "defcustom" form will use the saved value for initialization over
the standard value, provided that a saved value exists.

I guess the name "custom-set-variables" was a mistake.  It makes
people think of it as a command (like setq), rather than a
declaration.  It does not (in the prototypical case) set any
variables, it just mark what their saved value are for use when the
appropriate defcustom is evaluated.  

It should have been called "custom-saved-variables", that would have
avoided a lot of confusion.

Re: Getting more info on a variable in Customize buffers

[Robert J. Chassell]

    I guess the name "custom-set-variables" was a mistake.  It makes
    people think of it as a command (like setq), rather than a
    declaration. ...

>From what you are saying, it is very much a mistake.  The symbol
responds to `C-h f' (describe-function), which says

    custom-set-variables is a compiled Lisp function in `custom'.
    ...
    Initialize variables according to user preferences.

which tells me it is a function like `defvar'.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Getting more info on a variable in Customize buffers

[Reiner Steib]

On Sun, Jan 02 2005, Drew Adams wrote:

> 1) If I click Customize in the *Help* buffer from `C-h v', I arrive at a
> Customize buffer for only that variable, where there is no link to the
> custom group of the variable, so I can't see how it might be related to
> other variables in the group.

I get "Parent groups: [ediff-hook]".  There might be some variables
where the custom group declaration is missing.

Kim F. Storm pointed this out for several Gnus variables in
article <m3r7pdrc83.fsf@kfs-l.imdomain.dk>.

> 2) If I somehow get to the Customize group (ediff-hook) to customize the
> same variable, without coming from the `C-h v' *Help* buffer:
>
> 2a) The variable name does not appear as such. Instead, the name is
> prettified using title-case and replacing dashes with spaces. A variable
> with a mixed-case name like `Info-enable-edit' is indistiguishable in this
> format from one that is all lowercase. There is nothing that indicates to a
> user what the real name of the variable is and that the displayed name is a
> transformation of the real name.

Especially for TeX mode vs. AUCTeX variables this behavior is
irritating: `tex-offer-save' vs. `TeX-offer-save', ...

> For me, it would be more useful to show the real variable name than the
> title-case headline-style pretty name.

,----[ C-h v custom-unlispify-tag-names RET ]
| custom-unlispify-tag-names's value is nil
| 
| Display tag names as words instead of symbols if non nil.
| 
| You can customize this variable.
`----

> 2b) There is no link to the source code that defines the variable. You need
> to derive the real variable name from the pretty name and type that into
> `C-h v', just to get a link to the source code. Getting to the definition of
> a variable or function is one of the great strengths of Emacs over other
> programs. 

Yes, a button "Defined in `foo-bar'" next to "Parent groups" would be
useful.

> Doc strings are great, but they don't always substitute for looking
> at the real definitions. In Emacs, there is a progression from doc
> to code, and the two reinforce each other. Lack of a link to the
> defining code is an obstacle to that reinforcement.
>
> 2c) The variable value does not appear in its Lisp form. In some cases, it
> is possible to see the Lisp form, but in other cases it cannot be seen.

Isn't [State] / [Show initial Lisp expression] present for all
variables?

> So, I suggest:
>
>  - To the Customize buffer for a group containing a variable, we add:
>    1) the real variable name, in such a way that it can be copied
>       for pasting and searching and picked up by variable-at-point

How about a button that toggles `custom-unlispify-tag-names' and
re-displays the buffer?

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

ACK.

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

See above.

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

If the variable definition has a custom-manual entry like...

  :link '(custom-manual "(message)Mail Headers")

... you'll get a button "See also [Manual]." in the customize buffer.
See e.g. `message-ignored-mail-headers' and most other customizable
variables from `message.el'.

> Alternatively, we could eliminate the Customize buffer for an individual
> variable altogether. Clicking the Customize link in *Help* would instead
> take you to the correct entry in the Customize group buffer.

A variable may belong to two or more custom groups.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Getting more info on a variable in Customize buffers

[Andreas Schwab]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

>> 2c) The variable value does not appear in its Lisp form. In some cases, it
>> is possible to see the Lisp form, but in other cases it cannot be seen.
>
> Isn't [State] / [Show initial Lisp expression] present for all
> variables?

That only shows the initial value, not the customized one.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

    ,----[ C-h v custom-unlispify-tag-names RET ]
    | custom-unlispify-tag-names's value is nil
    |
    | Display tag names as words instead of symbols if non nil.
    |
    | You can customize this variable.
    `----

This is good to know. Thanks. As is often the case, what I think is sorely
missing is already there - I just didn't know about it.

Some minor problems I see in 21.3.50 from July 27 (maybe fixed since then):

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

- Changing it from t (default) to nil, and even setting it for
  the current session, and even saving it for future sessions
  is not reflected in the current current Customize buffer itself.

    How about a button that toggles `custom-unlispify-tag-names' and
    re-displays the buffer?

I suggested that each variable name itself serve as a toggle - click it to
change display of the name locally (but not change the variable
`custom-unlispify-tag-names').

Another omnipresent button just for toggling `custom-unlispify-tag-names'
might be overkill, but I agree that the option `custom-unlispify-tag-names'
should somehow be a bit more noticeable.

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.

Thanks too for the other info you mentioned. Luc mentioned many of the same
things, so see my reply to him.

 - Drew

Re: Getting more info on a variable in Customize buffers

[Stefan]

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

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

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.


        Stefan

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

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

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

Re: Getting more info on a variable in Customize buffers

[Per Abrahamsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> In fact, that is perhaps another, general problem: how to know how to
> customize Customize. 

M-x customize-group <ret> customize <ret>

Or from a customize buffer, select Custom -> Customize from the menu
bar (they are all there).

> If nothing else, I would hope that it would serve as an options
> browser (like `edit-options').

I like the customize-browse interface way better for browsing than
using customize-group.  Try it.

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

Because there were no user manual for customize at the time the :link
was added, and nobody have bothered to edit it since a customize
section was added to the user manual.  Please send a patch or a bug
report.

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

    > In fact, that is perhaps another, general problem: how to know how to
    > customize Customize.

    M-x customize-group <ret> customize <ret>

    Or from a customize buffer, select Custom -> Customize from the menu
    bar (they are all there).

That just brings up the customize buffer for the Customize group. I meant
that there is no doc that tells you _how to use the Customize UI_. I'm
thinking of a simple doc that describes the various UI features in a
Customize buffer (what you see, how it works).

Maybe a Customize buffer should be self explanatory, but it's not - look at
the custom-unlispify discussion and the discussion of what Show Initial Lisp
Expression really means, both in this thread.

    > If nothing else, I would hope that it would serve as an options
    > browser (like `edit-options').

    I like the customize-browse interface way better for browsing than
    using customize-group.  Try it.

I don't have a problem considering either one of those a browser for
customize.

My point was that Customize is not only a UI for _changing_ variable values:
it is also a browser for viewing information about variables (including
their values) and their interrelations (e.g. grouping into libraries).

I wrote the following in response to the claim that we shouldn't provide a
link to the source-code definition because if you need to look at the source
code then you shouldn't be using Customize:

  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.

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

    Because there were no user manual for customize at the time the :link
    was added, and nobody have bothered to edit it since a customize
    section was added to the user manual.  Please send a patch or a bug
    report.

Done: you just sent a bug report.

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

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

    Because there were no user manual for customize at the time the :link
    was added, and nobody have bothered to edit it since a customize
    section was added to the user manual.  Please send a patch or a bug
    report.

I changed that to point to Easy Customizations in the Emacs manual.

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

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

        Because there were no user manual for customize at the time
    the :link
        was added, and nobody have bothered to edit it since a customize
        section was added to the user manual.  Please send a patch or a bug
        report.

    I changed that to point to Easy Customizations in the Emacs manual.

I think that the "Help" button in the same buffer (not the "help" button,
which goes to the parent group, "help") already points there. If we don't
have a useful separate place for the "Manual" button to point, it should
just be removed.

As I mentioned, node Easy Customization in Info tells you a few things about
how to customize variables, but it doesn't really tell you about the
Customize UI. Because that UI is not yet ideal in terms of orientation,
navigation, how-to-use, and information provided, I think that some Info doc
on the Customize UI itself would be helpful.

Re: Getting more info on a variable in Customize buffers

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

> As I mentioned, node Easy Customization in Info tells you a few things
about
> how to customize variables, but it doesn't really tell you about the
> Customize UI. Because that UI is not yet ideal in terms of orientation,
> navigation, how-to-use, and information provided, I think that some Info
doc
> on the Customize UI itself would be helpful.

Yes, but maybe a GUI user normally do not read manuals?

- Lennart

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

    > As I mentioned, node Easy Customization in Info tells you a few things
    > about how to customize variables, but it doesn't really tell you about
the
    > Customize UI. Because that UI is not yet ideal in terms of
orientation,
    > navigation, how-to-use, and information provided, I think that some
Info
    > doc on the Customize UI itself would be helpful.

    Yes, but maybe a GUI user normally do not read manuals?

Right. I already lamented the fact that the Customize GUI is so poor that it
calls forth the need for doc on how to understand and use it. It should
instead be self-explanatory and understandable without any doc. No one wants
to read doc - especially just to figure out a user interface.

I don't like that state of affairs, but we should recognize it and provide
such doc as long as the problem exists. It is too often the case that doc
serves a palliative purpose, filling in for poor product design - especially
for GUIs.

But having such doc is better than not. Even just a list of "gotcha's" and
tips would help. For instance, everyone who reads this list now knows about
setting `custom-unlispify-tag-names' to nil - those who don't read this list
deserve to know that tip too.

Re: Getting more info on a variable in Customize buffers

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

> Right. I already lamented the fact that the Customize GUI is so poor that
it
> calls forth the need for doc on how to understand and use it. It should
> instead be self-explanatory and understandable without any doc. No one
wants
> to read doc - especially just to figure out a user interface.

The normal procedure to develop a GUI would be to ask users what aspect of
the GUI they do not for some reason like. (Of course the educated guess of
the developers are very, very good to have.) I guess a problem here is that
many users do not use the custom GUI. Therefore I believe every piece of
information we get about how different persons react to this interface is
important.

I think we should notice that GUIs are used "by intuition". I guess that is
what you are trying to point out.

BTW I use to hate it when I had to read the docs to find out how to pass the
glitches in the user interface. I soon use to realize that it is normally
not very much more work needed to get the GUI useable when you have the
basic structure. You mostly have to observe what is happening. But sometimes
that is just difficult when you doing things "by intuition".

- Lennaret

Re: Getting more info on a variable in Customize buffers

[Per Abrahamsen]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> Therefore I believe every piece of
> information we get about how different persons react to this interface is
> important.

Unfortunately, expert users are much more likely to provide feedback
then casual users.  Therefore, free software user interfaces tend to
be "expert friendly", rather then "beginner friendly".  An in
particular, cram way to much information and functionality into the
UI, scaring off beginners and casual users.

Which is fine in general, expert friendly software is very important.
But Emacs has always been expert friendly.  Expert users already have
an excellent interface for customizing Emacs, namely Lisp.  Customize
was supposed to add an *additional* interface in order to make
customization easier for casual users.  Drew Adams feedback seems to
build on the mistaken belief that Customize is the preferred way to
customize Emacs.  Which is far from the truth.  (I'd really like to
know which "Emacs priest" who gave him that belief, so I could explain
that they are spreading false gospel).

I do not believe there are any "preferred way" to customize Emacs.
There are a number of different mechanisms (Lisp, X resources, the
customize group interface, the customize browse interface, the
customize menu interface, The Options menu, edit-options,
set-variable, and customize-set-variable).  None of these are
obsolete.  Well, maybe "edit-options" is.  They are useful in
different situations, to different users.  And they mostly play along
together.

Re: Getting more info on a variable in Customize buffers

[Robert J. Chassell]

As Per Abrahamsen <abraham@dina.kvl.dk> said

   Unfortunately, expert users are much more likely to provide
   feedback then casual users.  Therefore, free software user
   interfaces tend to ... cram way to much information and
   functionality into the UI, scaring off beginners and casual users.

Or, sometimes `experts' push too much the other way.  This happened
with Gnome a year or two ago.  The `simple' interface did not let me
configure it as I liked.  (I don't know whether the bug still exists,
since I have not used that window manager since.)

The solution is straightforward:  always provide an `Advanced
customization' option.

After you have created a non-expert interface, which can only be done
by asking at least five non-experts to sit down and work with the
interface, you can provide a more advanced option.

(No one on this list is non-expert enough, not even me.  I don't know
five non-experts who would be willing to sit down.  Employing
non-experts is the kind of action I had expected some large company
that sells hardware or services to fund, but none have except for Sun
with one of the interfaces.  This befuddles me, since it is clearly in
companies' profit-oriented interest to increase the value of a
`complementary product'.  I do not understand MBAs.)

Since the customization commands are designed for Emacs novices and
for experts who mostly modify their .emacs files but who may prefer to
have it modified for them in occasional cases, as with faces, the `M-x
customize' interface and its siblings must be clear and easy.

  - It should show how everything is related, so novices can learn.

  - It should tell novices that the interface writes to their .emacs
    file (and of course the name should be one of the top
    customizations, even though most will not use it -- this is part
    of the educational task that customization has).

  - It should tell 
        the default for each item, 
        the various theme values, if any, 
        the previous value, if any, and 
        the current value.

Speaking of `expert friendly software', Per went on to say

   Which is fine in general, expert friendly software is very important.

Yes, very true.

   ... Drew Adams feedback seems to build on the mistaken belief that
   Customize is the preferred way to customize Emacs.  Which is far
   from the truth.

I am not sure Drew thinks that, but Per is right about the mistaken
belief.  A better way to customize Emacs is to write Emacs Lisp.  The
customize feature is supposed to be only a help for people who want to
see automatically written Emacs Lisp code in their .emacs file.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Getting more info on a variable in Customize buffers

[Lennart Borgman]

----- Original Message ----- 
From: "Robert J. Chassell" <bob@rattlesnake.com>

>   - It should show how everything is related, so novices can learn.

Agree. This is one of the most important aspects, since you can not do
everything through the customize GUI.

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

    > Therefore I believe every piece of
    > information we get about how different persons react to this
    > interface is important.

    Unfortunately, expert users are much more likely to provide feedback
    then casual users.

Unfortunately in some ways, but fortunately in others. I agree with your
statement (http://www.dina.kvl.dk/~abraham/rants/documentation-goals.html)
that "if your goal is to get qualified feedback, preferably in the form of
patches or at least useful bug reports, ordinary users aren't going to be
what you are after."

    Therefore, free software user interfaces tend to
    be "expert friendly", rather then "beginner friendly".  An in
    particular, cram way to much information and functionality into the
    UI, scaring off beginners and casual users.

Power users in the area of UIs give valuable feedback criticizing poor UIs.
The average free-software expert user might not be an expert on UIs, but
some no doubt are. People who are interested in UIs, whether expert users of
the particular UI or not, tend to take a UI-user point of view, just as
people interested in doc take a reader point of view. That's helpful.

I agree with your point, however, that feedback from users who are not
familiar with the application and its UI is 1) important and 2) hard to
obtain. In the current case, I am not a novice wrt Emacs, but I am a novice
wrt Customize. (We are all novices in some context.) Feedback from Emacs
users who are novices to Customize is useful (and apparently hasn't been
that hard to obtain :-)). Even if their ultimate use of Customize will not
be that of the primary target audience (non-Lispers), their feedback can
serve. (See below on the Customize audience.)

    Which is fine in general, expert friendly software is very important.
    But Emacs has always been expert friendly.  Expert users already have
    an excellent interface for customizing Emacs, namely Lisp.  Customize
    was supposed to add an *additional* interface in order to make
    customization easier for casual users.  Drew Adams feedback seems to
    build on the mistaken belief that Customize is the preferred way to
    customize Emacs.  Which is far from the truth.

Chalk it up to a mistaken impression on my part. And there are no priests to
out :-).

Beyond that mistaken impression, I also made the point that a Lisp user of
Emacs needs now to have some understanding of Customize (both the UI and the
customize functions) - if for no other reason than that reading the Lisp
source code now requires it. And writing library code requires it (per
priests). If you write code for users of a UI, you need some familiarity
with that UI (as a user and as a developer).

However, my main point was that dividing Emacs users into two mutually
exclusive sets - those who use Lisp and those who use Customize - is a
mistake. Customize should be aimed primarily at non-Lisp users, in the sense
that one should not _need_ to use or understand Lisp to be able to use
Customize. But that does not mean (to me) that Customize should not _also_
be useful for Lisp users of Emacs.

I mentioned the benefit of a good options browser to Lisp users as well as
beginners. I also pointed out that there are already many parts of the UI
that concern Lisp sexps and are obviously _not_ for beginners. There is
nothing wrong with that, as long as the UI does not place such stuff in the
way of non-Lisp users - it should not distract them; ideally, they would not
even see it. I agree with Bob Chassell that "Advanced Customization" is a
good (and typical) way to separate the sheep from the goats and still let
each stray to the other, apparently greener side if/when they wish.

In sum: Customize is for everybody, even if its primary raison d'etre is to
help non-Lisp Emacs users customize Emacs.

My other main point is that for Emacs aficionados, and _even more so for
Emacs novices_ (just a guess), the Customize UI has problems. Problems in
orientation, navigation, presentation, clutter, and semantic clarity. And
the same UI improvements will help both groups of user.

    I do not believe there are any "preferred way" to customize Emacs.
    There are a number of different mechanisms (Lisp, X resources, the
    customize group interface, the customize browse interface, the
    customize menu interface, The Options menu, edit-options,
    set-variable, and customize-set-variable).  None of these are
    obsolete.  Well, maybe "edit-options" is.  They are useful in
    different situations, to different users.  And they mostly play along
    together.

I agree with all of that. The last sentence is key here, however - I would
disagree with it if "mostly" weren't guarding it so well.

This thread has been about some ways in which Customize does _not_ play too
well with the rest (as well as about some general pbs with Customize). It
has included remarks from people for whom it is not clear how to do
customize-like or customize-compatible changes from Lisp (so that Lisp and
Customize will play well together). It has also included remarks from people
like me who feel that Customize should at least provide everything that `C-h
v' provides - for both Lisp users and novices (so that Lisp and Customize
will play well together).

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

    The normal procedure to develop a GUI would be to ask users what aspect of
    the GUI they do not for some reason like. (Of course the educated guess of
    the developers are very, very good to have.) I guess a problem here is that
    many users do not use the custom GUI. Therefore I believe every piece of
    information we get about how different persons react to this interface is
    important.

I agree.

One very useful way to get good info is to watch a beginner use custom
and say "please report anything you don't like AND anything that isn't
obvious how to use".  If a few people could do this with their
friends, over the coming weeks, that could potentially show us how to
make Custom more natural.  We may need to wait till after the release
before actually making the changes, but we will do it sooner or later.

Re: Getting more info on a variable in Customize buffers

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

> One very useful way to get good info is to watch a beginner use custom
> and say "please report anything you don't like AND anything that isn't
> obvious how to use".  If a few people could do this with their
> friends, over the coming weeks, that could potentially show us how to
> make Custom more natural.  We may need to wait till after the release
> before actually making the changes, but we will do it sooner or later.

Positive feedback is not too bad either ;-)

I should say that using imagination is very good. Try to get into the state
where you understand what is (or will) happening inside the "user". What
could change that? Since we may often be busy coding the ideas we already
have it might be difficult, but taking that time is useful!

Maybe you can also do this alone? Try to have a look at how the customize
GUI actually look now and frame your imagination inside that.

Re: Getting more info on a variable in Customize buffers

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

> One very useful way to get good info is to watch a beginner use custom
> and say "please report anything you don't like AND anything that isn't
> obvious how to use".  If a few people could do this with their
> friends, over the coming weeks, that could potentially show us how to
> make Custom more natural.  We may need to wait till after the release
> before actually making the changes, but we will do it sooner or later.

In an answer to this I have instead partly rewritten the customize GUI. The
rewrite is for Emacs 21.3.1 and is just a proposal (but a working one I
hope) for how the GUI could look and work. I have uploaded this to EmacsWiki
and you can find it on

  http://www.emacswiki.org/elisp/changelog.html

  The file name is cus-new-gui.el.

There are no real feature changes, just GUI changes. I feel they are mostly
just finishing work once begun on this GUI. The beginning of the file has
some comments about what I have done.

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

    I think that the "Help" button in the same buffer (not the "help" button,
    which goes to the parent group, "help") already points there. If we don't
    have a useful separate place for the "Manual" button to point, it should
    just be removed.

Ok.  If we want to write any additional documentation about how
to use Custom, we would put it into the Easy Customization node
which the Help button points to.

However, I would rather work on making the UI more natural
and intuitive than work on documenting it.

Re: Getting more info on a variable in Customize buffers

[Per Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

I kind of agree, I always thought there instead would be many more
"defsomething".  

The :get, :set and :init were, if I remember right, introduced by
XEmacs people for use with specifiers.  And since I didn't really care
about XEmacs (and certainly didn't understood specifiers to write a
defspecifier) I let them have their way.

And when it was there, it also got (ab)used in Emacs for minor modes.
It should have been part of a define-minor-mode instead, but as I
remember there already is was one of those.

It is simply too convenient to use these hooks to overload defcustom,
rather then define new "def-" whatever.

There also is a patch floating around here to overload defcustom for
keymaps as well.  Again, I can't come up with a good API for a
"defkeymap", and wouldn't find the time to implement it anyway.

Re: Getting more info on a variable in Customize buffers

[Stefan]

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

> I kind of agree, I always thought there instead would be many more
> "defsomething".  

> The :get, :set and :init were, if I remember right, introduced by
> XEmacs people for use with specifiers.  And since I didn't really care
> about XEmacs (and certainly didn't understood specifiers to write a
> defspecifier) I let them have their way.

Interesting.  And good to hear.

> And when it was there, it also got (ab)used in Emacs for minor modes.
> It should have been part of a define-minor-mode instead, but as I
> remember there already is was one of those.

We now have a proper `define-minor-mode' (which internally uses :set but
I guess that's OK).

> There also is a patch floating around here to overload defcustom for
> keymaps as well.  Again, I can't come up with a good API for a
> "defkeymap", and wouldn't find the time to implement it anyway.

I remember trying to introduce `defkeymap' but there wasn't much support for
it (it was a long time ago, way before the keymap-custom hack appeared).
Most/all keymaps are defined as something similar to:

  (defvar foo-map
      (let ((map (make-sparse-keymap)))
        (define-key map X1 Y1)
        (define-key map X2 Y2)
        (define-key map X3 Y3)
        (substitute-key-definition X4 Y4 map global-map)
        map))

so I suggested

  (defkeymap foo-map
     '((X1 Y1)
       (X2 Y2)
       (X3 Y3)
       (X4 Y4)))

with some additional options like :inherit and :suppress.  What it does
w.r.t Custom can then be adjusted as you please and improved over time.


        Stefan

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

      (defvar foo-map
	  (let ((map (make-sparse-keymap)))
	    (define-key map X1 Y1)
	    (define-key map X2 Y2)
	    (define-key map X3 Y3)
	    (substitute-key-definition X4 Y4 map global-map)
	    map))

    so I suggested

      (defkeymap foo-map
	 '((X1 Y1)
	   (X2 Y2)
	   (X3 Y3)
	   (X4 Y4)))

    with some additional options like :inherit and :suppress.  What it does
    w.r.t Custom can then be adjusted as you please and improved over time.

defkeymap appears to be just an abbreviation.  You could argue for
it as an abbreviation, but I don't see how it would have any effect
on what we can or can't easily do with Customize.

How would replacing the defvar with defkeymap affect Custom's handling
of this?

Re: Getting more info on a variable in Customize buffers

[Stefan Monnier]

>       (defkeymap foo-map
> 	 '((X1 Y1)
> 	   (X2 Y2)
> 	   (X3 Y3)
> 	   (X4 Y4)))

>     with some additional options like :inherit and :suppress.  What it does
>     w.r.t Custom can then be adjusted as you please and improved over time.

> defkeymap appears to be just an abbreviation.  You could argue for
> it as an abbreviation, but I don't see how it would have any effect
> on what we can or can't easily do with Customize.

> How would replacing the defvar with defkeymap affect Custom's handling
> of this?

There are two benefits:

1 - abbreviation, as well as a more declarative code.

2 - future updates to the definition of `defkeymap', for example to record
    all the keymaps defined, or to use the future keymap-support for Custom,
    or to make it easier for the user to define a binding in her .emacs for
    a keymap which will be loaded later, ...


-- Stefan

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

    1 - abbreviation, as well as a more declarative code.

That might be worth while.

    2 - future updates to the definition of `defkeymap', for example to record
	all the keymaps defined,

I don't see much use for that.

				 or to use the future keymap-support for Custom,

The way to define this for Custom would be with :type 'keymap,
so it doesn't particularly relate to defkeymap.

	or to make it easier for the user to define a binding in her .emacs for
	a keymap which will be loaded later, ...

That could be a benefit.  However, the magnitude of the benefit is
bounded by the difficulty of doing this now, and I think it is pretty
easy (just require the package you're going to customize before you
redefine its keymap).

Re: Getting more info on a variable in Customize buffers

[Stefan Monnier]

> 				 or to use the future keymap-support for Custom,

> The way to define this for Custom would be with :type 'keymap,
> so it doesn't particularly relate to defkeymap.

Of course it does: if you use `defkeymap', changing the definition of the
defkeymap macro is all that's needed to take advantage of ":type 'keymap"
when it finally appears.  With the usual `defvar', it requires changing each
and every `defvar'.  And if it later turns out that a (defcustom foo
... :type 'keymap) is not enough, you'll have to go through every keymap
definition all over again.

You seem to consider the cost of introducing a macro `defkeymap' to be
enormous (large enough that it needs very significant benefits to justify
itself).  The macro would probably be about 20 lines long and phasing in its
use is easy, so I see the cost as being negligible.


        Stefan

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

    You seem to consider the cost of introducing a macro `defkeymap' to be
    enormous (large enough that it needs very significant benefits to justify
    itself).

No, I said that you could argue for it as an abbreviation.

Re: Getting more info on a variable in Customize buffers

[Per Abrahamsen]

Stefan <monnier@iro.umontreal.ca> writes:

>> And when it was there, it also got (ab)used in Emacs for minor modes.
>> It should have been part of a define-minor-mode instead, but as I
>> remember there already is was one of those.
>
> We now have a proper `define-minor-mode' (which internally uses :set but
> I guess that's OK).

Not really, that is just fluff.  It still use a variable, so there is
(from a conceptual of view) no advantage of the current
`define-minor-mode' over defcustom.  It is just a thin piece of
syntactical sugar, with no real abstraction.

But using a variable for minor mode may be the best thing anyway,
since minor modes already by convention have a (real) associated
variable.  Overloading this variable, as is what we have done,
probably introduces less complexity than introducing a new "minor
mode" abstraction.

> so I suggested
>
>   (defkeymap foo-map
>      '((X1 Y1)
>        (X2 Y2)
>        (X3 Y3)
>        (X4 Y4)))
>
> with some additional options like :inherit and :suppress.  What it does
> w.r.t Custom can then be adjusted as you please and improved over time.

I believe the API, the UI, and save/load backend (for changes) has to
be designed together.  Comming up with an API or UI or even save/load
backend individually only makes the other parts way harder, like it
did for define-minor-mode.

Again, keymaps have an associated variable, so resuing that as was
done by Alex' hack again would probably be the right thing to do.

Re: Getting more info on a variable in Customize buffers

[Robert J. Chassell]

"Drew Adams" <drew.adams@oracle.com> wrote,

    If users who potentially would prefer Lisp names don't even know
    that displaying Lisp names is an option, then that is a loss.

It is even worse when it is not an evident option.  I just started a
plain vanilla Emacs using `emacs -Q' from an Emacs built on 28 Dec
2004.

In that instance of Emacs, I brought up the customization buffer for
`Escape Glyph' from by clicking on `escape-glyph' in *Faces*.

The *Faces* buffer does tell me the Lisp name.  

However, the *Customize Face: Escape Glyph* buffer does not.

I could not find any way of showing it by clicking on either of the
two buttons that showed some possibility:  `State' and `Value Menu'.

(As for the other buttons, I did not click on them because: I did not
want to see the parent groups, I did not want to hide the face, and it
looked to me that the generic commands, such as `Set for Current
Session' were not relevant.)

Perhaps I could do something different, but the action is not evident.
(The Info for (emacs)Easy Customization did not help either, not in a
quick look.)

Please, either stop trying to prettify names altogether or provide
both the prettified and proper name, as in

    Escape Glyph face, escape-glyph: (sample) Hide Face

rather than

    Escape Glyph face: (sample) Hide Face

Then those of us who would use customize for features we do not
understand, like faces, could actually use it.

Also, what is the equivalent command to `C-h v' (describe-variable)
for faces which are not variables?  `C-h C-h' (help-for-help) does not
tell, at least, not obviously.  (Please remember, all this is for
people who are not experts on the topic, so everything must be
obvious.)

Thank you.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Getting more info on a variable in Customize buffers

[Stefan Monnier]

> The *Faces* buffer does tell me the Lisp name.
> However, the *Customize Face: Escape Glyph* buffer does not.

Could you tell us why you want to know the face's name?

> Also, what is the equivalent command to `C-h v' (describe-variable)
> for faces which are not variables?

Huh?  Have you tried M-x describe-face?


        Stefan

Re: Getting more info on a variable in Customize buffers

[Robert J. Chassell]

   Could you tell us why you want to know the face's name?

Yes, so I can check that a customize command did the right thing when
I look at the `custom-set-faces' expression in my .emacs file.  My
`user-init-file' is set to the actual name of my .emacs file, so the
command works on the correct file.

A customize command may write the file, but I do like checking it.
(Also, of course, we encourage non-hackers to do this sort of thing.)
And sometimes I modify the expression in my .emacs file.

   > Also, what is the equivalent command to `C-h v' (describe-variable)
   > for faces which are not variables?

   Huh?  Have you tried M-x describe-face?

That command does not offer an Emacs Lisp expression to put into my
`custom-set-faces' expression in my .emacs file.  It should provide a
name and an expression, somewhat like this:

    eshell-prompt-face 

    ((t (:foreground "Pink" :weight normal)))

(I.e., like setting `custom-unlispify-tag-names' to nil and then
pressing return when point is over the `State' button and then
selecting option #9, Show as Lisp expression.  Except that doing that
shows the previous value unless I `Set for Current Session' first; and
then `Reset' fails to take me back to the previous setting.....)

If the `describe-face' command did provide an Emacs Lisp expression
and were documented in the Customize buffer where a novice would find
it readily, then it could be useful.

(Incidentally, in addition to showing the lisp expression in a
appropriate field, the `Documentation:' field of the `describe-face'
command should tell one to use `custom-set-faces' rather than `setq'.
The `one' may be a novice or have forgot how to deal with faces.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Getting more info on a variable in Customize buffers

[David Kastrup]

Stefan <monnier@iro.umontreal.ca> writes:

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

AFAIR, set-variable by now obeys the :set function.  So everything
that is user-visible behaves consistent.

`setq' OTOH is "low-level".  Perhaps we should warn people in the
introduction to writing .emacs that setq or setq-default might not do
the trick for user-settable variables.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Getting more info on a variable in Customize buffers

[Luc Teirlinck]

David Kastrup wrote:

   AFAIR, set-variable by now obeys the :set function.  So everything
   that is user-visible behaves consistent.

No, that was never implemented.  I do not know whether we still want
to implement it before the 21.4 release.  It does not seem very
difficult for setting default values, but setting buffer local values
still would not call the :set functions (because :set functions are
designed to set _default_ values and hence often can not be used to
set buffer local values).  So it would definitely not make everything
user-visible consistent, even if implemented.

Sincerely,

Luc.

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

       AFAIR, set-variable by now obeys the :set function.  So everything
       that is user-visible behaves consistent.

    No, that was never implemented.  I do not know whether we still want
    to implement it before the 21.4 release.  It does not seem very
    difficult for setting default values, but setting buffer local values
    still would not call the :set functions (because :set functions are
    designed to set _default_ values and hence often can not be used to
    set buffer local values).

We could add defcustom properties :get-local and :set-local
to handle local values.  This could be useful for running Custom
buffers to set things locally, also.

Re: Getting more info on a variable in Customize buffers

[Stefan Monnier]

>        AFAIR, set-variable by now obeys the :set function.  So everything
>        that is user-visible behaves consistent.

>     No, that was never implemented.  I do not know whether we still want
>     to implement it before the 21.4 release.  It does not seem very
>     difficult for setting default values, but setting buffer local values
>     still would not call the :set functions (because :set functions are
>     designed to set _default_ values and hence often can not be used to
>     set buffer local values).

> We could add defcustom properties :get-local and :set-local
> to handle local values.  This could be useful for running Custom
> buffers to set things locally, also.

Currently :set and :get are supposed to work buffer-locally if
custom-local-buffer is non-nil.


        Stefan

Re: Getting more info on a variable in Customize buffers

[Luc Teirlinck]

Stefan Monnier wrote:

   Currently :set and :get are supposed to work buffer-locally if
   custom-local-buffer is non-nil.

Actually it is quite confusing.  The default :set function is
`custom-set-default' for `custom-theme-set-variables' (and for the
defcustom docstring) and `set-default' for all the rest of the Custom
machinery.  Is there some rationale behind that?  What is the intended
use?  For interactive use, `custom-local-buffer' seems to inconvenient
(even if it worked reliably, which it does not).

Anyway, any case where `custom-set-default' would be used seems
irrelevant to the discussion.  In the cases where it works, it does not
do anything different from what `set-variable' currently does.  What
we discussed was calling the :set function if there was a _non-default_
:set function.  Most of these were not designed to work buffer-locally.

The best way to make set-variable work buffer-locally depends on
whether and how we want to make Custom work buffer-locally.  If we do
not care about making Custom set buffer-local values, the best thing
would probably be :set-local and :get-local keywords, as Richard
suggested.  That _maybe_ could also be the case if we wanted to make
Custom work buffer-locally.

Making Custom work buffer locally is very tricky.  It does not seem
like something for before the next release.

The question is whether we still want to change something to
`set-variable' before the next release.

Sincerely,

Luc.

Re: Getting more info on a variable in Customize buffers

[Stefan Monnier]

> Making Custom work buffer locally is very tricky.  It does not seem
> like something for before the next release.

Actually, I doubt it's even useful because buffer-local customizations can't
be usefully saved in a .emacs.  What I'd rather want (as a user) is mode-local
customizations.


        Stefan

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

    Actually, I doubt it's even useful because buffer-local customizations can't
    be usefully saved in a .emacs.  What I'd rather want (as a user) is mode-local
    customizations.

I think that buffer-local customizations are somewhat useful even if
they cannot usefully be saved.  (And maybe they can be saved, if you
use desktop.)

However, mode-local customizations are a good idea for a future feature.

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

    The best way to make set-variable work buffer-locally depends on
    whether and how we want to make Custom work buffer-locally.

We want to make Custom work buffer-locally.  This is not super-urgent,
but it is very desirable for the long term.

      For interactive use, `custom-local-buffer' seems to inconvenient
    (even if it worked reliably, which it does not).

Of course this is not meant as an end-user interface.  It is meant
as a mechanism for the end-user interface to use.  For that purpose,
it is clean enough.

								 If we do
    not care about making Custom set buffer-local values, the best thing
    would probably be :set-local and :get-local keywords, as Richard
    suggested.  That _maybe_ could also be the case if we wanted to make
    Custom work buffer-locally.

I had forgotten about custom-local-buffer.  Now that I remember it, I
see no advantage in :set-local and :get-local.  The :set and :get
functions can just as easily test custom-local-buffer.

    Making Custom work buffer locally is very tricky.  It does not seem
    like something for before the next release.

If specific :set and :get functions fail to handle custom-local-buffer,
that is a bug.  We can fix these bugs at any time.  Would you like
to find some cases that fail, and fix them?

Adding a nice UI so that Custom uses custom-local-buffer is a
different job.  We might not want to install that now; however, people
could start implementing it now, to be installed later.

Re: Getting more info on a variable in Customize buffers

[Luc Teirlinck]

Richard Stallman wrote:

   If specific :set and :get functions fail to handle custom-local-buffer,
   that is a bug.

They are _currently_ not really bugs (at least not user visible bugs),
since there currently are no situations where custom-local-buffer can
be meaningfully used.  From the moment we start using
custom-local-buffer they would become (user visible) bugs.

   We can fix these bugs at any time.

Yes, except that time spent doing that means less time spent working
toward a release.  We only have a motivation to spend time on that
_before_ rather than _after_ the release if we plan on using
`custom-local-buffer' meaningfully before the next release.

   Would you like to find some cases that fail, and fix them?

I could look at those defcustoms that I am very familiar with, but
that is a very small fraction of all defcustoms with :set functions
that are out there.  (Fortunately, :get functions appear to be very
rare.)  For many :set functions it may not be immediately obvious what
the best way to make them work buffer-locally is, and there are tons
of defcustoms with :set functions.

The only reason to worry about making :set and :get functions work
buffer locally now would be to allow `set-variable' to call the :set
functions buffer locally.  But if we try to do that _now_, the next
release will be full of newly introduced bugs, because we will not
be able to come even remotely close to adapt all :set functions.

The next release seems already remote enough that I do not believe
that we should delay it further by trying to change the behavior of
`set-variable' right now.

All of this is not a question about what should be done, but whether
it should be done for 21.4 or for 22.

Sincerely,

Luc.

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

    They are _currently_ not really bugs (at least not user visible bugs),
    since there currently are no situations where custom-local-buffer can
    be meaningfully used.

They are bugs, and I invite people to fix them.
They are not urgent, but it isn't bad to fix them.

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

      Perhaps we should warn people in the
    introduction to writing .emacs that setq or setq-default might not do
    the trick for user-settable variables.

It already says this in the node Init Syntax.

Re: Getting more info on a variable in Customize buffers

[drkm]

Stefan <monnier@iro.umontreal.ca> writes:

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

  So a big difference between variables and customs is:

    - with a variable, you can `setq' it before evaluate its
      definition, to overload its default value.  It's very convenient
      in .emacs.  For example, you don't have to load any library to
      change the variable value;

    - with a custom, you have to wait its definition to be evaluated
      before setting it in any way, to have its :get and al. to be
      known.  So you have to deal with `require' or `eval-after-load'
      in .emacs, or correctly load autoloads file if provided (and if
      it contains the desired defcustom form).

  Right ?

  If it is, I don't know any standard way to do that directly in
ELisp, if I don't want to use Customize.  I think about something
like :

    (defmacro set-custom (custom value lib)
      (if (boundp custom)
          `(set-variable ',custom ,value)
        `(eval-after-load ,lib
           '(set-variable ',custom ,value))))

  But for using it, I have to know CUSTOM to be defined as a custom,
where it is defined, etc.  And this doesn't deal with non-evaluating
the "default value form" (in defcustom) if `set-custom' is evaluated
before loading the LIB.

  This point can be important if the custom' value is used when
loading the file, for example to compute the default value of another
variable:

    (defcustom a-custom 'default
      "..."
      :set ...)

    (defvar a-internal-var (compute a-custom))

  How can I do in this case to change the value of `a-custom' (and
have `a-internal-var' correctly set)?  Hum, I suppose it's the
responsability of the :set'er of `a-custom'...

  So what's the clean way to set custom' value in ELisp, in a user
point of view?

--drkm

Re: Getting more info on a variable in Customize buffers

[Lennart Borgman]

Maybe you could use (custom-set-variables ...)

Though you have to know how the values look when written. But should not
that "do the right thing"?

But there is more to it of course, controlling what to save etc. When
looking at the code in custom I got the feeling that there are needed some
break up of the code so it is easy to do handle the variables from code. For
example I just copied some code to find out whether it would be possible to
customize a variable.

- Lennart


----- Original Message ----- 
From: "drkm" <darkman_spam@yahoo.fr>
...
>   If it is, I don't know any standard way to do that directly in
> ELisp, if I don't want to use Customize.  I think about something
> like :
>
>     (defmacro set-custom (custom value lib)
>       (if (boundp custom)
>           `(set-variable ',custom ,value)
>         `(eval-after-load ,lib
>            '(set-variable ',custom ,value))))
>
>   But for using it, I have to know CUSTOM to be defined as a custom,
..

Re: Getting more info on a variable in Customize buffers

[drkm]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> Maybe you could use (custom-set-variables ...)

  I thinked I had seen that `custom-set-variables' have to be used
only once.  I can't find where I have see that.  Maybe it's a mistake
from me.

> Though you have to know how the values look when written. But should not
> that "do the right thing"?

  I don't know verry well the Custom package, but it seems to be the
right way to do that.  It is ?  By the way, Info doc maybe lacks these
informations.

--drkm

Re: Getting more info on a variable in Customize buffers

[Per Abrahamsen]

drkm <darkman_spam@yahoo.fr> writes:

>   So what's the clean way to set custom' value in ELisp, in a user
> point of view?

The doc string of each customize variable that cannot be set reliably
simply by setq, is supposed to describe how to set it from Lisp.
Usually this means calling the same specialized "inialization"
functions as the customize interface does.

If some doc strings doesn't do this, report it as a bug.

Re: Getting more info on a variable in Customize buffers

[Per Abrahamsen]

"Drew Adams" <drew.adams@oracle.com> writes:

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

It is a generic problem that customize variables are only visible when
a package is loaded.  It should be fixed, but for all variables, not
by adding autoloads for individual variables.

There is certainly nothing that merrits treating
'custom-unlispify-tag-names', at the time where you are annoyed that
the variables are unlispyfied, you are most likely to be in a
custimize buffer (and thus, have cus-edit.el loaded).

> I suggested that each variable name itself serve as a toggle - click it to
> change display of the name locally (but not change the variable
> `custom-unlispify-tag-names').

A tooltip would be better.  But I think the UI is already overloaded.
Given the target audience of customize, the UI should be kept much
more minimal than it is.

Setting custom-unlispify-tag-names to nil by default might be better,
I don't remember why we ended up with the current value.

Re: Getting more info on a variable in Customize buffers

[Lennart Borgman]

----- Original Message ----- 
From: "Per Abrahamsen" <abraham@dina.kvl.dk>

> It is a generic problem that customize variables are only visible when
> a package is loaded.  It should be fixed, but for all variables, not
> by adding autoloads for individual variables.

Agree. At least for now there should be a possibility to test whether a
custom var could be customized at the moment. Such a function can be written
easily be breaking up customize-option. This function would anyway be good
to have for packages are not part of Emacs (or not searched for vars).

- Lennart

RE: Getting more info on a variable in Customize buffers

[Drew Adams]

    > I suggested that each variable name itself serve as a toggle
    > - click it to
    > change display of the name locally (but not change the variable
    > `custom-unlispify-tag-names').

    A tooltip would be better.

How would a tooltip help? The idea is to toggle the display. Are you
suggesting a tooltip with instructions of how to customize
`custom-unlispify-tag-names'?

    But I think the UI is already overloaded.
    Given the target audience of customize, the UI should be kept much
    more minimal than it is.

It is certainly very *&!BUSY+@~, but that is mainly a problem of:

1) poor choice of visuals: large, bold type for simple names, 3D buttons for
everything, whether it is really a link, a menu, or an action button.

2) some poorly chosen names and poorly positioned buttons and info.

Other UIs have even more overloading, in fact, in the sense of there being
some things you can click by discovery that provide extra info or minor
display changes - without the UI appearing overwhelming (busy, loud,
confusing, disorienting).

There is nothing wrong with having a relatively unimportant UI element be
active in some minor way (e.g. tooltip, display toggle). But important UI
elements should have their active functionalities be obvious (e.g. links,
menus, buttons should be easy to recognize).

    Setting custom-unlispify-tag-names to nil by default might be better,
    I don't remember why we ended up with the current value.

That would be a good start.

Re: Getting more info on a variable in Customize buffers

[Richard Stallman]

    1) If I click Customize in the *Help* buffer from `C-h v', I arrive at a
    Customize buffer for only that variable, where there is no link to the
    custom group of the variable, so I can't see how it might be related to
    other variables in the group. It might be that what I really need is a
    similarly named variable, but I can't browse the group to find it. In fact,
    I can't even see what custom group the variable belongs to (no group name is
    indicated).

It would be useful for these buffers to include a link to move to
the whole group.  One complication is that the variable can belong
to more than one group.  I am sure that complication can be overcome.

I don't want to implement this, but if someone else does, it can
be installed.

    2a) The variable name does not appear as such. Instead, the name is
    prettified using title-case and replacing dashes with spaces. A variable
    with a mixed-case name like `Info-enable-edit' is indistiguishable in this
    format from one that is all lowercase.

I have always been uncertain whether this prettifying of names is
a good thing.  I am still not sure.