Re: Customize buttons that change user's custom fileshouldaskforconfirmation

["Lennart Borgman" <lennart.borgman.073@student.lu.se>]

lennart.borgman.073@student.lu.se
Lund


----- Original Message ----- 
From: "Kim F. Storm" <storm@cua.dk>


> Miles Bader <snogglethorpe@gmail.com> writes:
>
> > Your table helps, but I think it's important to use the proposed
> > operations, not what the current code does.  Here's my version:
> >
> >    Set:            Field => Current
> >    Save:           Field => Current, Saved
> >
> >    Get Current:    Current => Field
> >    Get Saved:      Saved => Field
> >    Get Default:    Standard => Field

Yes, it is more easy to understand (at least for me). But what happened to
Erase Customization? I do not believe that this always can be done with Get
Default+Save.


> To summarise:
> =============
>
> I suggest the following button names:
>
>   <Set>  <Save>  <Cancel>   <Clear All>
>
> The <Set> button does "F => C" when enabled/confirmed.
>
> This is an expert command, so it shall be disabled by default
> (e.g. like narrow-to-region), causing Emacs to ask the novice user if
> he really wants to do this.

I think the situation is a bit different for Emacs than for other
applications. In most applications the options are easy to understand and
set. It is not so for all options in Emacs. Therefore I believe that a
novice user really can benefit from beeing able to Set and test before Save.


> The <Save> button does "F => C,S" and thus "C => S" when F == C.

Yes, it does Set+Save. Can anyone find any reason to break this up?


> The <Cancel> button does either "C => F" or "S => C,F".

The <Cancel> idea has some benefits but I see two problems. First this would
give one question for every option in the customization buffer. Second
<Cancel>  normally means something like "discard unsaved changes and close
window/frame".


> The <Clear All> button first asks the user for confirmation.

> If ok it does "D => F"  (does not update C or S).

Is not this the same idea as Miles have+confirmation? (And the same problem
with the missing "Erase"?) Why a confirmatin in this case?

> It then prints a message
>    Remember to use <Set> or <Save> to activate/save the values.

Good idea. Customize does something similar today.

> Also the user should be offered to save unsaved customizations when he
> exits emacs.

Yes, but...


-----------
* My summary:*

1) I like Miles suggestion, it is easy to understand, but there should be an
"Erase" too.

2) Maybe the semantics of "Get *" must be pointed out, since it is probably
not an operation that the user has seen somewhere else.

3) I believe that Kims concern for that the interface must easy to
understand from what the user knows from other applications should be met as
far as possible. The exact words are as important as the semantics here. For
example currently customize speaks about "the text in this buffer" - I
believe that it should speak about "fields" instead (where appropriate).

4) Messages guiding the user are important (but they are no excuse not
trying to make them obsolete by even better design).

5) Options are however more complicated sometimes in Emacs. "Set" should
therefore be availabe for testing. (And we should try to make the options
more simple.)

6) Offer to save: yes, but where? I would suggest when closing the customize
buffer.