Inconsistency in whole buffer buttons.

Inconsistency in whole buffer buttons.

[Luc Teirlinck]

A while ago, I made the whole buffer "Erase Customization" button ask
for confirmation.  Now all whole buffer buttons (and functions) ask
for confirmation.  For multi-option buffers, that is an improvement.

But there is a difference in single option buffers.  The way I
implemented "Erase Customization", it does _not_ ask for confirmation
in single option buffers.  The others do.  The behavior should be made
uniform in single option buffers one way or the other.  I could easily
make the behavior uniform in either way.

Maybe the way in which we choose to make the behavior uniform depends
on the future direction we want to take for Custom (after the
release).  If we want to go in the direction explained below, it might
be better _not_ to bother the user with confirmation questions in single
option buffers.

Below is my opinion on Custom after the release:

In practice, people already right now use the whole buttons nearly
exclusively in single option buffers, where they are not confusing or
dangerous and do not need confirmation any more than the State Menu
items do.  In single option buffers, the State Menu button is
redundant and all State Menu items that currently have no whole buffer
buttons could be given whole buffer buttons, maybe under the heading
"Advanced".  Then the State button could be deleted from single option
buffers.

In group (or other multi-option) buffers, it may be difficult for
beginners to figure out exactly what the whole buffer buttons and
functions operate on.  The answer is that do _not_ operate on hidden
options nor on options that have been changed outside Custom or are
otherwise "rogue".  (There are very good reasons for that.)  Even for
advanced users who know exactly what they operate on, they are
essentially useless, because if you operate on an entire large Custom
buffer, it just is _way_ to easy to overlook something, confirmation
or no confirmation.

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.

Sincerely,

Luc.

RE: Inconsistency in whole buffer buttons.

[Drew Adams]

    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.

Re: Inconsistency in whole buffer buttons.

[Luc Teirlinck]

Drew Adams wrote:

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

The concrete immediate question in this thread was, should the whole
buffer buttons ask for confirmation in single option buffers?  The
only reason to do so would be uniformity of behavior among Custom buffers.

The reason why I mentioned possible changes after the release is that
I believe that the situation in single option buffers is so different
from that in multi-option buffers that it would be good to make them
_less_ alike after the release to rationalize the look and behavior of
both.

Sincerely,

Luc.

Re: Inconsistency in whole buffer buttons.

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Drew Adams wrote:
>
>    Regarding Luc's proposals for changes after the release (sorry for the
>    length) -
>
> The concrete immediate question in this thread was, should the whole
> buffer buttons ask for confirmation in single option buffers?  The
> only reason to do so would be uniformity of behavior among Custom buffers.

It is superfluous to ask for confirmation in single option buffers, so we
shouldn't do that.  I doubt this will be confusing to anybody.  OTOH, it
did confuse me the first time emacs asked me to confirm saving all options
in a multi-option buffer ... but I can live with that.
>
> The reason why I mentioned possible changes after the release is that
> I believe that the situation in single option buffers is so different
> from that in multi-option buffers that it would be good to make them
> _less_ alike after the release to rationalize the look and behavior of
> both.

I don't follow the logic of this -- IMO, the layout and the
functionality of the buttons should be the same in both cases --
except for trivial differences.

One such trivial difference would be to not requiring confirmation in
single option buffers.  I don't think that will confuse anybody.

If the buttons behave very differently in multi and single option
buffers, the functionality of the buttons should be fixed, rather 
than trying to make the buffers less similar ...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Inconsistency in whole buffer buttons.

[Richard M. Stallman]

    It is superfluous to ask for confirmation in single option buffers, so we
    shouldn't do that.

That's what I've decided.

Re: Inconsistency in whole buffer buttons.

[Richard M. Stallman]

    But there is a difference in single option buffers.  The way I
    implemented "Erase Customization", it does _not_ ask for confirmation
    in single option buffers.  The others do.  The behavior should be made
    uniform in single option buffers one way or the other.  I could easily
    make the behavior uniform in either way.

I think it is best if none of the buffer buttons
asks for confirmation in a single-option buffer.

    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.

I don't like that idea.  I think that an option should look the same
whether there are other options in the buffer or not.

    Multiple-option buffer: whole buffer buttons and other whole buffer
    functionality only available upon setting a defcustomed option,
    disabled by default.

I don't think I like that.

Re: Inconsistency in whole buffer buttons.

[Luc Teirlinck]

Richard Stallman wrote:

   I think it is best if none of the buffer buttons
   asks for confirmation in a single-option buffer.

I have implemented this and installed it in CVS.

Sincerely,

Luc.

Re: Inconsistency in whole buffer buttons.

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Richard Stallman wrote:
>
>    I think it is best if none of the buffer buttons
>    asks for confirmation in a single-option buffer.
>
> I have implemented this and installed it in CVS.

Personally, I'd use a different criterion: ask for confirmation if the
operation would change more than a single option, regardless of how
many options there are in the buffer.

And warn if the operation does not change any option (like when
prospective options are hidden).

I don't know how feasible this is, but I think that would more or less
be what I consider as natural.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Inconsistency in whole buffer buttons.

[Luc Teirlinck]

David Kastrup wrote:

   Personally, I'd use a different criterion: ask for confirmation if the
   operation would change more than a single option, regardless of how
   many options there are in the buffer.

   And warn if the operation does not change any option (like when
   prospective options are hidden).

   I don't know how feasible this is, but I think that would more or less
   be what I consider as natural.

It would be more complex and it is not worth it.  The present
criterion for asking for confirmation is reasonable and easily
understood.  There is evidence that nobody really intentionally uses
these buttons in multi-option buffers.  So spending a lot of time
trying to figure out what the absolutely most perfect criterion would
be and then implementing it, even if it is a lot more complex, makes
no sense.  On the other hand, there is evidence that people do use
these buttons in single-option buffers, where asking for confirmation
was an unnecessary inconvenience.

I believe that the situation (with regard to asking for confirmation)
after the changes I implemented yesterday is better than the situation
before I implemented them and I also believe that it is good enough.

I believe that the introductory text for these buttons should tell
what they operate on, as I proposed yesterday.

Sincerely,

Luc.

Re: Inconsistency in whole buffer buttons.

[Richard M. Stallman]

    Personally, I'd use a different criterion: ask for confirmation if the
    operation would change more than a single option, regardless of how
    many options there are in the buffer.

I think the current criterion makes more sense.

Re: Inconsistency in whole buffer buttons.

[Richard M. Stallman]

       I think it is best if none of the buffer buttons
       asks for confirmation in a single-option buffer.

    I have implemented this and installed it in CVS.

Thanks.