feedback on customize -- apropos-groups et al

feedback on customize -- apropos-groups et al

[Drew Adams]

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

Re: feedback on customize -- apropos-groups et al

[Richard Stallman]

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

M-x customize RET shows you information about customize groups.
The top of the Custom buffer has a Help link to the manual's description.

    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?

I don't understand.

    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:

How should a link look?

RE: feedback on customize -- apropos-groups et al

[Drew Adams]

   M-x customize RET shows you information about customize groups.
   The top of the Custom buffer has a Help link to the manual's description.

You're right. Sorry, operator ignorance. Don't know how I missed the Help
button. (Button overdose, perhaps.)

       3. possible to have a version of the Info section on customize
          that reflects the UI on a window system?

   I don't understand.

Info is text-only; the customize interface I see (with a window system) has
buttons and looks a bit different. That's all.

       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:

   How should a link look?

Like a link in Info, for instance, or in common Web browsers. Info links
don't interfere much with reading the text. By default they are just blue
text (purple for visited links). I think this was maybe my main message:
just change buttons that are not action buttons to look like Info links. And
using a different link color for visited links ("buttons"), as in Info, also
helps navigation.

Re: feedback on customize -- apropos-groups et al

[Lennart Borgman]

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

:    How should a link look?
:
: Like a link in Info, for instance, or in common Web browsers. Info links
: don't interfere much with reading the text. By default they are just blue
: text (purple for visited links). I think this was maybe my main message:
: just change buttons that are not action buttons to look like Info links.
And
: using a different link color for visited links ("buttons"), as in Info,
also
: helps navigation.

In many surveys about web pages it is found that users mostly want web page
links to look just like default links. This is blue underlined. Maybe this
would be good for Emacs too?

- Lennart

Re: feedback on customize -- apropos-groups et al

[Richard Stallman]

    In many surveys about web pages it is found that users mostly want web page
    links to look just like default links. This is blue underlined. Maybe this
    would be good for Emacs too?

Does this change do what you suggest?  What do people think of it?

*** info.el	08 Sep 2004 11:41:08 -0400	1.401
--- info.el	11 Oct 2004 03:37:05 -0400	
***************
*** 79,86 ****
    :group 'info)
  
  (defface info-xref
!   '((((class color) (background light)) :foreground "blue")
!     (((class color) (background dark)) :foreground "cyan")
      (t :underline t))
    "Face for Info cross-references."
    :group 'info)
--- 79,86 ----
    :group 'info)
  
  (defface info-xref
!   '((((class color) (background light)) :foreground "blue" :underline t)
!     (((class color) (background dark)) :foreground "cyan" :underline t)
      (t :underline t))
    "Face for Info cross-references."
    :group 'info)
***************
*** 455,460 ****
--- 455,461 ----
  
  ;;;###autoload (add-hook 'same-window-regexps "\\*info\\*\\(\\|<[0-9]+>\\)")
  
+ ;;;###autoload (put 'info 'info-file "emacs")
  ;;;###autoload
  (defun info (&optional file buffer)
    "Enter Info, the documentation browser.
***************
*** 1791,1796 ****
--- 1792,1799 ----
    "Build table of contents from menus of Info FILE and its subfiles."
    (if (equal file "dir")
        (error "Table of contents for Info directory is not supported yet"))
+   (if (equal file "history")
+       (error "Table of contents for history list is not meaningful"))
    (with-temp-buffer
      (let* ((default-directory (or (and (stringp file)
                                         (file-name-directory
***************
*** 3258,3263 ****
--- 3261,3267 ----
  			   (car elt)
  			 elt))
  		 (file (if (consp elt) (cdr elt) elt))
+ 		 (case-fold-search nil)
  		 (regexp (concat "\\`" (regexp-quote name)
  				 "\\(\\'\\|-\\)")))
  	    (if (string-match regexp (symbol-name command))

Re: feedback on customize -- apropos-groups et al

[Richard Stallman]

    Like a link in Info, for instance, or in common Web browsers. Info links
    don't interfere much with reading the text. By default they are just blue
    text (purple for visited links). I think this was maybe my main message:
    just change buttons that are not action buttons to look like Info links.

That sounds feasible.  Does anyone object to the idea?  Does anyone
offer to implement it?

RE: feedback on customize -- apropos-groups et al

[Drew Adams]

Yes, underlined is better, by default. It is what people are used to, and
the underline indicates clearly (conventionally) that something is a link.

      users mostly want web page links to look just like default links. This
      is blue underlined.
   Does this change do what you suggest?  What do people think of it?

Re: feedback on customize -- apropos-groups et al

[Lennart Borgman]

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

I agree!

: Yes, underlined is better, by default. It is what people are used to, and
: the underline indicates clearly (conventionally) that something is a link.
:
:       users mostly want web page links to look just like default links.
This
:       is blue underlined.
:    Does this change do what you suggest?  What do people think of it?

Re: feedback on customize -- apropos-groups et al

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     In many surveys about web pages it is found that users mostly want web page
>     links to look just like default links. This is blue underlined. Maybe this
>     would be good for Emacs too?
>
> Does this change do what you suggest?  What do people think of it?

I initially thought that since unlike Web browsers Info buffers have
no other text highlighted in blue besides Info links, so additional
distinction by underlining is not needed.

But if the goal is to make Info links look exactly like Web links,
I have no objections against this.

-- 
Juri Linkov
http://www.jurta.org/emacs/