unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* feedback on customize -- apropos-groups et al
@ 2004-10-09 19:31 Drew Adams
  2004-10-10 15:16 ` Richard Stallman
  0 siblings, 1 reply; 9+ messages in thread
From: Drew Adams @ 2004-10-09 19:31 UTC (permalink / raw)


Here is some feedback from a customize newbie. Forgive me if some of the
requested enhancements already exist in some form. I haven't found them, so
perhaps they need to be made more noticeable in that case.


Customize is _good_, for several reasons, including:

 - structured, hierarchial organization, with corresponding navigation
 - centralized, one-stop shopping for editing and inspecting options
 - types, to control option values

I especially appreciate the last one. There are no doubt other important
advantages to customize.

What I _don't_ like about customize, perhaps only partly because I haven't
spent enough time with it, is this: I get bogged down, sometimes even lost,
navigating, and I can't always quickly find what I'm looking for. It's
sometimes hard to see the forest for the trees.

Suggestions --

1. Users may get to a customize buffer before having read the Emacs manual
section on customize. It would be useful to put a small "Help" link to that
manual section at the top of each customize buffer.

The mode-line link to the mode description does not help much -- the
description of custom-mode is _skimpy_, and does not really describe the
mode in a way that helps you use it. Users need to be guided to _Info_.

`C-h m' gives 253 lines of stuff (!) that is mostly about mostly irrelevant
minor modes like auto-compression. The info on custom-mode itself is
essentially 11 lines of key-binding descriptions -- keys that do only what
the UI buttons do. So, `C-h m' gives no more information about the customize
buffer than what you see in the buffer already. I'm not saying that `C-h m'
should do what Info does; I'm saying that if it is to do anything useful at
all, it should at least guide you to Info.

  [BTW, Wouldn't it be a good idea in general to have a link from
  `C-h m' help sections (at least the major mode section) to the
  corresponding Info manual sections, if any?]

  [BTW2, I think there was some discussion about removing all minor-mode
  stuff to different pages (accessible from links). I support that,
  and custom-mode is a good example of the problem.]


2. By way of analogy, here's what I typically do to find and modify a
variable:

 a. apropos, to find appropriate variables -- this can include different
members of the apropos family, such as searching doc strings
 b. describe-variable
 c. set-variable (or setq...), or click link in *Help* to go to customize

This is usually very _quick_. If I don't find what I'm looking for by
searching (apropos) for "enlarge", I try "increase", "grow", "expand" etc.

How do I find information about customize groups? How do I find information
about the organization of customize itself?

 - Analogous to (a), it would be helpful to have an `apropos-groups' command
that would let you see which groups match the apropos string, with a brief
description of each. Likewise, for a command that looks for group names in
doc strings.

 - Analogous to (b), there is no `describe-group' command, but if there were
it would provide the same info provided by the customize buffer for the
group. So, it could help to have such a command that just took you to the
group's customize buffer.

 - An overall _Table of Contents_ for customize would also be useful.
Navigating the customize tree is OK, but it isn't the best way to get the
big picture -- too tedious and too much like looking at a landscape through
a tube.

 - An _Index_ for customize would be very helpful: groups, variables,
everything important in the realm of customize.


3. I don't know the policy on accessibility or platform compatibility, but I
wonder if it wouldn't be possible to have a version of the Info section on
customize that reflects the UI on a window system?  Even if the UI is
different on different window systems, it would still be easier to follow
one of them than the text-only version.

We would of course still also need a text-only version for using Info
without a window system. I'm guessing that Texinfo would allow this kind of
single-sourcing, to produce different Info versions.


4. As to customize itself, it would be clearer if buttons that acted only as
links looked like links. Buttons should be reserved for real _actions_. Too
many buttons(!) -- most of which are not. Also, instead of having this:

 Picture group: [Go to Group]

just get rid of the button and put a link on the text "Picture group". With
simple changes like these, the buffer will not be so cluttered and
overwhelming. Currently, it looks like the control center for a nuclear
reactor; all that's missing are buttons that start to flash yellow and red.
;-)


HTH,

  Drew

^ permalink raw reply	[flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-10-12 14:48 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-09 19:31 feedback on customize -- apropos-groups et al Drew Adams
2004-10-10 15:16 ` Richard Stallman
2004-10-10 16:47   ` Drew Adams
2004-10-10 19:14     ` Lennart Borgman
2004-10-11 16:45       ` Richard Stallman
2004-10-11 17:03         ` Drew Adams
2004-10-11 17:13           ` Lennart Borgman
2004-10-12 14:48         ` Juri Linkov
2004-10-11 16:46     ` Richard Stallman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).