From: "Drew Adams" <drew.adams@oracle.com>
Subject: feedback on customize -- apropos-groups et al
Date: Sat, 9 Oct 2004 12:31:16 -0700 [thread overview]
Message-ID: <MEEKKIABFKKDFJMPIOEBMELMCGAA.drew.adams@oracle.com> (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
next reply other threads:[~2004-10-09 19:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-09 19:31 Drew Adams [this message]
2004-10-10 15:16 ` feedback on customize -- apropos-groups et al 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MEEKKIABFKKDFJMPIOEBMELMCGAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).