RE: Customize buttons that change user's custom fileshouldaskforconfirmation

[Drew Adams]

    Customize operates with four values for each variable:   
    F * the field value
    C * the current value
    S * the saved value
    D * the default value  
    It provides commands for the following operations:  
    F => C
    F => C,S
    C => S
    C => F
    S => C,F
    D => C,F  or  D => F

    In contrast, most other applications only have these states:
    F * the field value
    A * the active (current/saved) value
    D * the default value
    ...

Clear analysis and presentation.

    Consequently, I think the ability to set an option without saving
    it is unfamiliar to most users -- when you set something and apply
    the change, they will expect it to be like that from now on.

Yes, but it is not unfamiliar to most _Emacs_ users. And if it is
unfamiliar to newbies, then we have to help them to understand. Emacs
is more about dynamic, current values than it is about saved settings,
and yes, that is different from what newbies might be used to. This
idea should be at the forefront of our Customize UI model. Customizing
Emacs is a real-time thing; saving changes is just an option. It's
essential that we make clear this difference between customizing in
Emacs and in other applications.
    
    IMO, we should consider the difference between F and C states as
    an expert option.

I disagree. I do not think we want to change the model or make the C
operations for expert-mode only - it would be very confusing to do
so. "Set" is the _first_ thing, not the last thing, that we want
novices to try; it should definitely not be disabled by
default. Learning to use and customize Emacs implies, first and
foremost, learning about changing dynamic values. We just need to make
the UI clear, so that users realize what each action does.

Sure, you can save changed values once you get what you want, but what
makes Emacs different is the ease with which you can modify things on
the fly and see if that is what you like. Customize is only one way to
do that, but it is no exception - it lets you change current values
without saving them.

Novices more than anyone else need to know that they can make all the
changes they want, play with them, and exit with no lasting
consequences. They already know there is (there must be) a way to save
changes; what they might not know is that they don't _need_ to save a
change in order to have it take effect. This "sand-box" mode is the
norm for Emacs.

IOW, since the Emacs model is different, we need to make that
difference clear from the outset, not hide it behind a presentation
that pretends at first sight to be the same old change=save model. A
user must not need to progress to "expert" status to be able to change
things with no permanent consequences. Sand boxes are for novices more
than anyone else.
    
    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.

Good point. We need to somehow make crystal clear that the buttons and
menubar menu items apply to _each_ option in the buffer. Possible ways
include 1) using the word "All" in menu and button names and 2) asking
for confirmation, warning that _all_ options are concerned. I think
that using "All" in the names would be good and sufficient. Whenever a
user saves values, however, we should of course ask for confirmation.
    
    Also the user should be offered to save unsaved customizations
    when he exits emacs.

Agreed. We've discussed this before - perhaps we can do that after the
release. I have a prototype that does this (as an option); if you want
to see what this might be like, you can try it at
http://www.emacswiki.org/elisp/cus-edit-plus.el (Food for thought only
- I'm not proposing the code for inclusion in Emacs.)
    
    Another idea is to combine "C => F" and "S => C,F" states into a
    single <Cancel> option.  We can do this by letting <Cancel> check
    if C != S and ask the user: Restore to last saved value (y/n)
    in that case -- otherwise it just restores to C (== S).

Not a bad idea. But if we do that, the question posed should give the
user the option of resetting to a) the current value, b) the saved
value, or c) the standard value. That is, we could have a single Reset
button with a menu - in fact, I think we already have essentially this
behavior, as an option: the Reset menu (`custom-reset-menu').
        
    I suggest the following button names:
    
      <Set>  <Save>  <Cancel>   <Clear All>

Since each of these operates on everything in the buffer, they should
each use the word "All" (Set All, Save All, Cancel All, Clear All) -
or else we should find some other way to make that very clear. In any
case, "Clear All" should not be different from the others in this
respect.

Clear All is not the right name for this, in any case. The term
"Clear" commonly refers to merely emptying an edit field. We don't
have such an operation (and we don't need it) - the closest operation
we have is what you are calling Cancel. Cancel and "Clear All" will be
confused.

Is there any question that these are the operations we want? I think
they are. 

    F => C               (Set)
    F => C,S             (set-and-save, which should be called Save)
    C => S               (Save)
    C => F               (Reset from Current)
    S => C,F             (Reset from Saved)
    D => C,F  or  D => F (Reset from Standard)

To the right are the names I prefer. We could combine the last three
into a single Reset button, as mentioned above.

However, it might be confusing to combine resetting edit fields with
resetting current values. Since we have a Set button, why not confine
the reset buttons to resetting only the edit field (F)? That is:

    C => F   (Reset from Current)
    S => F   (Reset from Saved)
    D => F   (Reset from Standard)

Using the combined Reset buttons would mean we have only Set, Save,
and Reset.

Any reset action should display a feedback message saying 1) that
(all) the _edit fields_ have been reset from <source> and 2) you can
_set_ the current values to these fields with Set.

 - Drew