RE: Inconsistency in whole buffer buttons.

["Drew Adams" <drew.adams@oracle.com>]

    So my idea for after the release would be:

    Single option buffers: all current State Menu items become whole
    buffer buttons (some under a heading "Advanced"), no State button.

    Multiple-option buffer: whole buffer buttons and other whole buffer
    functionality only available upon setting a defcustomed option,
    disabled by default.  _Maybe_ a State Menu button as now, _maybe_ a
    "Customize" button (or link) that if you click on it sets up a single
    option buffer.  If the latter, users could replace it with the current
    State Menu button using another customizable option.

    In other words, for beginning users, group and other multi-option
    buffers could be pure browsing tools, actual customization happens in
    single-option buffers, after clicking the appropriate "Customize"
    button.  I have even heard several advanced users say that they only
    customize in single option buffers.  I myself use the State buttons.

I would like us to discuss Customize generally, after the release -
especially, but not only, the UI.

For now, I'd like to thank Luc for 1) looking so closely at the workings of
customize (I'm glad someone understands how it works!) and 2) making good
suggestions and changes to Customize for the current release. I think we'd
lose a lot without his careful attention to detail. Customize is a bear to
use and a bear to get right (design & implementation).

I hope we do make the effort to revisit customize after the release, though
that might call into question some of the changes made now. Anyway, what Luc
has proposed for this release sounds good to me.


Regarding Luc's proposals for changes after the release (sorry for the
length) -

Wrt single-option customize buffers:

- Is the only difference that between a menu and separate buttons? If so,
this is without great consequence. Buttons are better for this, provided
there are not too many of them. However, the same actions should also be
available in 1) a menu-bar menu and, perhaps, 2) a mouse-3 popup menu. I
think Luc's point is that the raison d'etre for the State menu is to provide
a local choice for a single preference within a buffer of multiple
preferences - so, such a menu isn't needed in a single-preference buffer.


Wrt the proposed options for dealing with multi-preference customize
buffers, we should discuss this more after the release, but, for now:

- What's convenient for advanced users is also convenient for novices: 1) If
it is convenient to _see_ multiple preferences (e.g. faces) together when
you operate on one (e.g. State menu), then this is even more important for
non-experts. 2) If it is convenient to _operate_ on multiple preferences all
at once (e.g. global button), then this is just as important for
non-experts. We should either keep global buttons or get rid of them - for
everyone.

- If we keep global buttons (or equivalent menu items or whatever) that
operate on multiple preferences all at once, each button action should: 1)
explicitly list the preferences that will be affected or those that will
*not* be affected (or perhaps both?), whichever group is smaller, and 2)
require confirmation. We might need to finagle this so it isn't too clumsy,
but we need to somehow explicitly let the user know that foo will *not* be
affected and toto and titi will be affected. See alternative suggestion,
below.

- I'd prefer letting (that is, making) the user explicitly choose the
preferences to act on. It is convenient to be able to act on several at once
(vs repeating the action on each separately). But, for example, a user might
want to save several, but not all, of the preferences s?he has changed. That
is, the set of targets to act on should be decided by the user, not by
program. The program can guess what the user might want to act on, but the
user should at least confirm that selection and, preferably, should be able
to modify the selection.

- One way to do this would be to provide a check box next to each preference
in the buffer and 1) precheck the boxes of those preferences that the
program thinks could be targets (e.g. all changed preferences could be
targets for saving), but 2) let the user change the target set by
checking/unchecking individual boxes. #2 is analogous to a user marking
multiple files in Dired for performing some action. (#1 has no analogy in
Dired.)

- We might also make it possible for a user to check/uncheck multiple boxes
at once, by selecting those preferences (drag a region) and using a popup
menu item Mark Selected (or Unmark Selected). I do that, for instance in an
enhancement to Dired, and something similar is commonly used in Windows
Explorer (not Internet Explorer, but the Windows imitation of Dired plus
speedbar).

- If we disallowed making multiple changes together, and instead, as
suggested by Luc, let users open a separate customization buffer by clicking
a "Customize" button (there's a problem of overloading "customize", here,
BTW), we should open that buffer in a separate window, so users can continue
to see the other, related preferences. This is mainly important for faces:
It's helpful to be able to see the result of customization (the new face
appearance) at the same time as the appearance of other, related faces.

I have other thoughts on improving customize after the release, as I'm sure
others do also. One thing I would really like to see affects any buffer that
uses widgets, not just customize buffers: Be able to do `C-h k' (or
equivalent) on a widget, to see what Lisp function it ultimately applies.
You can do this with a menu item, but not with a widget (button, etc.).

That drives me crazy when I try to figure out what the customize code is
actually doing, and how it does so. What we have, IIUC, is partial OOP, and
it doesn't seem to fit too well with the rest of Emacs (in the sense just
given).

I have a similar problem with menu items that are generated dynamically.
Here's what you see, for instance, if you do `C-h k' and pick File > Print >
PostScript Print > Buffer > 1-up:

  <menu-bar> <file> <Print> <PostScript Print> <Buffer> <1-up> runs the
  command menu-function-33 which is an interactive Lisp function.

  It is bound to <menu-bar> <file> <Print> <PostScript Print> <Buffer>
<1-up>.
  (menu-function-33)

  Not documented.

Besides being redundant (key foo runs command bar, which is bound to key
foo), this tells you less than you started with! It takes you from a partly
meaningful description of the key (the menu item itself: 1-up PostScript
printing of a buffer) to something completely opaque: `menu-function-33'
(for which there is no further info). Thanks, but no thanks.

Emacs is great, in part, because you can drill down from the UI to the
source code transparently. The opacity imposed by such dynamically created
menus and by widgets is an obstacle to understanding. I would love to see
such obstacles removed, though my guess is that that wouldn't be trivial to
accomplish.

Thanks again to Luc (and others) for chipping away at the customize code.