RE: Customize buttons that change user's custom fileshouldaskforconfirmation

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

        The big problem is that if the user sets option X on a page and does
        <Set> "F => C", and then (sometime later) sets option Y on the same
        page, and then does <Save> "F => C,S", the effect is that the change
        to X is also saved.  This may be highly confusing to a user.

This is confusing now only because the button doesn't properly indicate that
the action is to Save All. As we discussed, renaming the button (All) and
asking for confirmation should take care of this. ("This will save all
options in the buffer that have been Set. Do you want to continue?").

    One possible solution for that is to discourage, or even get rid of,
    of the per-variable command button.  If there is only the whole-buffer
    Set and the whole-buffer Save, this confusion won't happen.

    ISTR that I have seen apps where there is no difference between the
    field value and the active value within the customization tool, but
    all the changes require confirmation when you exit the customization
    tool.

    The concept of "exiting" does not make sense for a Custom buffer, but
    there could be a buffer-wide Activate command, "Put this in effect",
    which combines Set and Save.

That's just what the Save button does currently, IIUC.

    If that were the only way to make values
    take effect, it would be a lot simpler than the current Custom
    facility.

    In addition to Activate, there would be Cancel and Standard Values.
    And perhaps What's Changed, which says what would change if you use
    Activate right now.

    What do people think of the idea?

I think that it would be a very bad idea to move away from being able to
manipulate (e.g. edit, set, reset, & save) individual options. A given
custom buffer will perhaps have many options in several different states.
There must be a way to save one or more options in the buffer but not
necessarily all. Otherwise, we will get more confusion and operator error.

We might want to let users select a set of individual options (e.g. using
checkboxes or by dragging a region) and then operate on the selection. That
would provide a shortcut to operating individually on each item in the set,
and could help make it clear which options were affected for a "global"
operation.

But to always use the entire Customize buffer as that selection would be
restrictive, IMO.

WRT the idea of checkboxes - I'm thinking of what we do in Dired to mark
(select) files for applying actions. You can use many different ways to mark
a file (regexp etc.). In my own Dired code, you can also:

 - Use the mouse to drag a region, then use a mouse-3 menu item Mark (or
Unmark) to select (or deselect) all the files in the region. If no region is
active (no selection), then the mouse-3 menu items affect the single file
under the pointer.

 - Use SHIFT and CONTROL with mouse-1 clicks to select blocks of files or
individual files to add to the selection set - just as you do in Windows
Explorer.

Extending this idea to Customize, a user would mark/select various options,
then use a global action (button or menu-bar menu item) that operates on all
of the selected options. If no options are selected, then the menu item
would apply to the option under the pointer.

The menu for this is the individual-option menu, which is currently accessed
by the State "button". This could remain as a pulldown menu (which is what
it really is now), or it could be moved to a contextual menu on mouse-3 (as
I have in Dired). In the latter case, mouse-3 would not be available for
selecting and killing, but users could still select a region by dragging.

I assume that this discussion applies to possible changes after the release,
not before.