[Top][All Lists]

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

Re: Getting more info on a variable in Customize buffers

From: Reiner Steib
Subject: Re: Getting more info on a variable in Customize buffers
Date: Sun, 02 Jan 2005 21:25:07 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

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 <address@hidden>.

> 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

> 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

> 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


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

reply via email to

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