RE: Visual cleanup for customize buffers

[Drew Adams]

    > Basically, the "Apply-OK-Cancel" interface becomes
    > completely disfunctional once you apply it to a
    > customization buffer containing several options that
    > can be set to complex values.  That is also why the
    > Custom whole buffer buttons are completely
    > disfunctional in multi-option buffers.
    
    I completely disagree!
    
    This is a well-known customization interface, which
    suits its purpose quite well in most applications, so I
    just don't see why you claim it is completely
    disfunctional in Emacs.

I don't think it's completely dysfunctional (if fixed), but
I think it's necessarily inadequate for Emacs. See below.
    
    If we have BOTH the whole buffer "apply ok cancel"
    buttons, AND the individual STATE buttons, I cannot
    understand why the "apply ok cancel" buttons need any
    magic behaviour -- they should simply apply to ALL
    modified options (in the buffer).  There's nothing
    disfunctional about that IMO.

Even without the show/hide monstrosity, the problems are
that 1) you don't know what you're getting (what changes
will be saved) and 2) you cannot modify that set of save
candidates.

    Let me repeat my point of view:
    
    The problem is not the whole buffer buttons as such;
    rather it is the completely obscure functionality of
    those buttons -- where you really need to be an expert
    to understand what they do.  Just fix the functionality
    to do the "natural thing" (and keep the State buttons
    for the advanced/expert users who want finer control).
    
There is more than one issue that has been raised about the
whole-buffer buttons:

1. Luc pointed out that there are currently problems wrt
   acting on or not acting on changes that are hidden. Kim's
   point about this is, I think, that things could be
   simplified so that there would be no such hide/show
   problems with whole-buffer buttons: hiding info should
   not having anything to do with which preferences are
   acted upon. 

   I don't think Luc disagrees with that (I don't, in any
   case), though Luc might disagree that it will be simple
   to solve all of the hide/show problems. However, a) we're
   not there yet (the problems exist, today) and b) that is
   anyway not a sufficient argument in favor of a simple
   Save All button or a simple Apply-Ok-Cancel UI, because
   it does not address the other arguments that have been
   raised (see below).

2. I pointed out that Emacs lets users change preferences
   without necessarily saving them. This is a big difference
   from most applications. A UI that automatically saves all
   changes (on exit via `OK') loses the advantage that Emacs
   offers in this area. Being able to change multiple
   preferences and experiment with them without
   automatically saving is something we should not give up.

3. I pointed out that not only can you set preferences
   without saving them, but Emacs sessions are typically
   much longer than those of other apps. These two facts,
   together, mean that a button that simply saves all
   changes is not appropriate. You might have changed many
   preferences, perhaps over a long period of time, and you
   might even have forgotten some of those changes.

   Users need to be informed of just what has changed and so
   will potentially be saved, and asked for their
   confirmation before saving. It would be better to also
   let users select or deselect changed preferences for
   saving. IOW, because of the decoupling of setting and
   saving, there is a need to determine which changes to
   save - a one-size-fits-all Save button isn't good enough.

   And the individual State buttons don't serve well here
   either. You don't want to be _required_ to explicitly act
   on each preference separately. You want to be able to
   quickly save all of them, if appropriate, after review,
   or quickly save all except a few that you uncheck.

4. I expect interactive customization to be extended beyond
   what is strictly the Customize buffer UI. That is, I hope
   that other ways of changing preference values will in the
   future work hand-in-glove with Customize, so that you
   can, for example, use a handy graphic tool or command to
   change face properties, yet still take advantage of the
   Customize UI to save such changes, undo them, or tweak
   them further. That is, I'd like to see the Customize UI
   recognize (at least some) changes made outside it as
   being equivalent to changes made inside it.

   If this happens, it too will argue against having only a
   simple Save All button and in favor of informing users of
   what potentially needs saving and letting them choose
   which changes to save. This is really the same as
   argument #3, but it strengthens that argument by
   extending its scope. No matter which preferences are
   changed, or how they are changed, the Customize UI should
   help you recognize unsaved changes and make it easy for
   you to save those you want to save.

Think of `customize-customized' - that should be the first
building block of any whole-buffer Save function for
customize. At the very least, clicking a whole-buffer Save
button should do the equivalent of `customize-customized'
for the preferences in the current Customize buffer, so you
see what changes you're saving. We can obviously do better
than simply displaying a separate list of the changed
preferences, but we need this _functionality_ of informing
the user of what's changed, in one form or another.