Re: Customize buttons that change user's custom file should ask forconfirmation

Re: Customize buttons that change user's custom file should ask forconfirmation

[Richard Stallman]

    Instead of "Erase Customizations":
    1) "Default Values" - resets to default (= installed) settings

    2) "Save" - the existing button. It would update the custom
       file to use the installed settings.

Does anyone object to this change?
It seems to me that this would eliminate a
potential cause of "user error" in Custom.

Re: Customize buttons that change user's custom file should ask forconfirmation

[Stefan Monnier]

>     Instead of "Erase Customizations":
>     1) "Default Values" - resets to default (= installed) settings

>     2) "Save" - the existing button. It would update the custom
>        file to use the installed settings.

> Does anyone object to this change?
> It seems to me that this would eliminate a
> potential cause of "user error" in Custom.

More than that, I think it's The Right Thing to do. (IMNSHO, there should
only ever be *one* way to save changes.  E.g. in `cvs' it's `cvs commit').


        Stefan

Re: Customize buttons that change user's custom file should ask forconfirmation

[Miles Bader]

> More than that, I think it's The Right Thing to do. (IMNSHO, there should
> only ever be *one* way to save changes.  E.g. in `cvs' it's `cvs commit').

I agree with you, but I'll note that there does seem to be trend in
some quarters towards eliminating the notion of saving altogether,
e.g., in Gnome preferences (of course I think this simply yet another
step in Gnome's increasing UI bogosity; no doubt they got the idea
from somewhere though...).

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Customize buttons that change user's custom file should askforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>
>     Instead of "Erase Customizations":
>     1) "Default Values" - resets to default (= installed) settings

I would prefer "Reset to Defaults".

>     2) "Save" - the existing button. It would update the custom
>        file to use the installed settings.

There is one logical problem. Should this work just on the symbols in the
current customization buffer or on all values? What if there are several
customization buffers in use?

I would prefer that it worked just on the current customization buffer and
that there were a menu entry for saving all changed values for defcustom
symbols.

Re: Customize buttons that change user's custom file should askforconfirmation

[Miles Bader]

On Mon, 31 Jan 2005 02:16:50 +0100, Lennart Borgman
<lennart.borgman.073@student.lu.se> wrote:
> ----- Original Message -----
> From: "Richard Stallman" <rms@gnu.org>
> >     Instead of "Erase Customizations":
> >     1) "Default Values" - resets to default (= installed) settings
> 
> I would prefer "Reset to Defaults".

I don't think that's good -- it smacks too much of the old behavior;
"Reset" seems to imply more than just changing the values being edited
in the current buffer.

I think Drew's wording is good.

> >     2) "Save" - the existing button. It would update the custom
> >        file to use the installed settings.
> 
> There is one logical problem. Should this work just on the symbols in the
> current customization buffer or on all values? What if there are several
> customization buffers in use?
> 
> I would prefer that it worked just on the current customization buffer 

I don't understand your point ... the only reasonable method would be
operating on the current buffer -- the whole point of this proposed
change is that the button only makes a temporary change in the current
buffer until it's saved.

> and
> that there were a menu entry for saving all changed values for defcustom
> symbols.

I don't understand that at all.

-Miles
-- 
Do not taunt Happy Fun Ball.

RE: Customize buttons that change user's custom file should askforconfirmation

[Drew Adams]

    >     2) "Save" - the existing button. It would update the custom
    >        file to use the installed settings.

    There is one logical problem. Should this work just on the
    symbols in the
    current customization buffer or on all values? What if there are several
    customization buffers in use?

    I would prefer that it worked just on the current customization
    buffer and
    that there were a menu entry for saving all changed values for defcustom
    symbols.

In my mind, unless obviously relative to only particular values (e.g.
contextual popup menu, local button), all Customize buttons and menu items
would apply only to the buffer contents.

Re: Customize buttons that change user's custom file should askforconfirmation

[Per Abrahamsen]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> ----- Original Message ----- 
> From: "Richard Stallman" <rms@gnu.org>
>>     Instead of "Erase Customizations":
>>     1) "Default Values" - resets to default (= installed) settings
>
> I would prefer "Reset to Defaults".

Emacs terminology is a bit messed up here, in that default-value refer
to the value that in not buffer local.  

Customize is "standard" instead of "default" in the code for that
reason.  Of course, that need not be reflected in the UI.

RE: Customize buttons that change user's custom file should askforconfirmation

[Drew Adams]

    >>     Instead of "Erase Customizations":
    >>     1) "Default Values" - resets to default (= installed) settings
    >
    > I would prefer "Reset to Defaults".

    Emacs terminology is a bit messed up here, in that default-value refer
    to the value that in not buffer local.

    Customize is "standard" instead of "default" in the code for that
    reason.  Of course, that need not be reflected in the UI.

Good point.

If we did not have this dilemma, then "Default Values" would be good to use
in the customize UI (it is commonly used to mean this in user-preference
dialogs). But we do, so we should avoid confusing users with two kinds of
"default" value.

It would be good to have two different terms for the two different kinds of
default value, so that we don't have to describe the context each time. One
is the standard value for a user option (variable or face), where "standard"
essentially means defined by defcustom or defface (IIUC). The other is the
value a variable has in a buffer if there is no buffer-local value
(setq-default).

Our choices are to rename the customize term or the global-value term.

- If we rename the customize term, then I think "Standard Values" might be
good, as used in the customize code. Another possibility to consider for
this might be "Installed Values" (or "Stock Values").

This standard value is apparently redefined each time defcustom is executed
for a variable, which perhaps argues against using "installed" as the term
(although multiple defcustoms for the same variable shouldn't exist or
should be rare).

- If we instead rename the global-value term, and use "default" value to
mean the standard value of customize, then we will need to change existing
references to default values in the sense of non-local values
(setq-default), to call them "global" values (or something similar). But
then `setq-default' would become a misnomer. Also, in this case, only user
options would have default values; variables that are not `user-variable-p'
would not.

"Standard Values" seems best to me, so far.

Re: Customize buttons that change user's custom file should askforconfirmation

[Robert J. Chassell]

   ... Another possibility to consider for this might be "Installed
   Values" (or "Stock Values").

"Stock Values" is best.  It will cause me to ask, `what is meant by 
"stock values" ... ?'  

Like anyone who is not a novice Emacs person, I follow the convention
and set values in my .emacs file.  Only for features that I do not
understand, like fonts, do I use customize.  And, of course when I
realize I made a mistake and can see a better face, I change the
customized values that I have set within my .emacs file by
`custom-set-faces'.

Asking what is meant by "stock values" is worthwhile for people who
have used Emacs for two decades or more -- for example, off hand, I
cannot remember whether `customize' considers stock values to be those
you see with `emacs -Q' or whether it uses the previously set values.
And the phrase is harmless to novices.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

RE: Customize buttons that change user's custom file shouldaskforconfirmation

[Drew Adams]

       ... Another possibility to consider for this might be "Installed
       Values" (or "Stock Values").

    "Stock Values" is best.  It will cause me to ask, `what is meant by
    "stock values" ... ?'

    Like anyone who is not a novice Emacs person, I follow the convention
    and set values in my .emacs file.  Only for features that I do not
    understand, like fonts, do I use customize.  And, of course when I
    realize I made a mistake and can see a better face, I change the
    customized values that I have set within my .emacs file by
    `custom-set-faces'.

    Asking what is meant by "stock values" is worthwhile for people who
    have used Emacs for two decades or more -- for example, off hand, I
    cannot remember whether `customize' considers stock values to be those
    you see with `emacs -Q' or whether it uses the previously set values.
    And the phrase is harmless to novices.

IIUC, the "standard" (stock, or whatever) values are those defined by
defcustom and defface; that's all - the values according to "the spec" (Spec
Values? Defined Values?).

This term does not determine a particular set of options; it refers only to
a particular kind of value for an option - any option. Emacs -Q just uses a
minimal set of libraries and features, so a minimal set of options. Standard
values apply to defcustoms and deffaces from all libraries.

Re: Customize buttons that change user's custom file should askforconfirmation

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    ... Another possibility to consider for this might be "Installed
>    Values" (or "Stock Values").
>
> "Stock Values" is best.  It will cause me to ask, `what is meant by 
> "stock values" ... ?'  

I'll second that.

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

Re: Customize buttons that change user's custom file should askforconfirmation

[Stefan Monnier]

>> ... Another possibility to consider for this might be "Installed
>> Values" (or "Stock Values").
>> 
>> "Stock Values" is best.  It will cause me to ask, `what is meant by 
>> "stock values" ... ?'  

> I'll second that.

Agreed: if additionally to "options" you start talking about "stock values",
I'm gonna start wondering when the FSF moved to Wall Street and why FSF
members weren't informed,


        Stefan

Re: Customize buttons that change user's custom file should askforconfirmation

[Simon Josefsson]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> ... Another possibility to consider for this might be "Installed
>>> Values" (or "Stock Values").
>>> 
>>> "Stock Values" is best.  It will cause me to ask, `what is meant by 
>>> "stock values" ... ?'  
>
>> I'll second that.
>
> Agreed: if additionally to "options" you start talking about "stock values",
> I'm gonna start wondering when the FSF moved to Wall Street and why FSF
> members weren't informed,

Maybe members will get stock options?

Seriously, "stock values" sound a bit odd in my ears (I'm not a native
speaker though).  "Preset values"?  I dunno.

Re: Customize buttons that change user's custom file should askforconfirmation

[Lennart Borgman]

> "Robert J. Chassell" <bob@rattlesnake.com> writes:
>
> >    ... Another possibility to consider for this might be "Installed
> >    Values" (or "Stock Values").
> >
> > "Stock Values" is best.  It will cause me to ask, `what is meant by
> > "stock values" ... ?'
>
> I'll second that.

For one whos mother tongue is not english "Stuck" seems ok too.

I regret my earlier post on this. "Standard Values" are perhaps the best so
far. Maybe "Original Values" is good too. "Default Values" are perhaps most
easy to understand for those who did not read the code.

Re: Customize buttons that change user's custom file should askforconfirmation

[Per Abrahamsen]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> I regret my earlier post on this. "Standard Values" are perhaps the best so
> far. Maybe "Original Values" is good too. "Default Values" are perhaps most
> easy to understand for those who did not read the code.

Original values are not got, it could easily refer to any historical
value before the latest change.

A big argument for "standard value" is that this is the term we came
up with last time this was discussed (I originally called it factory
setting, but RMS didn't knew that term), and the term used internally
in customize.

Re: Customize buttons that change user's custom file should askforconfirmation

[Robert J. Chassell]

    I'm gonna start wondering when the FSF moved to Wall Street ...

Good point.  I never thought of that.  Over all, on further
investigation, the interface needs more work, not just some rewording.

Using `emacs -Q' from 26 Jan 2005, 

I use 

    M-x customize-face RET secondary-selection RET

and change the face background from yellow to red
and the press the `Save for Future Sessions' button.

(By the way, where does an `emacs -Q' save settings, since it does not
load a .emacs file.  Does it create one?  If not, does the button fail
to save but not show a message telling this?  If so, this is bug
zero.)

When I the press the `Save for Future Sessions' button, the sample
turns red, as expected.

I then press the `Erase Customization' button, the sample turns yellow
as expected, but the `Background' attribute is not ticked and does not
show yellow.  This is bug one.

Bug two occurs when I then press the `Reset to saved' button:  nothing
happens, even though I had saved a new value, a red background.

Then I tick the `Background' attribute.
Bug three:  it shows `black' instead of yellow.

I change the `black' to `green' and press the `Save for Future
Sessions' button.  The sample turns green, as expected.

Bug four:  unfortunately, when I then press the `Reset to saved'
button, the sample does not turn red as it should, but stays green.

Bug five:  I then press the `Erase Customization' button with the
mouse over the `m' of the word `Customization', but nothing happens
the first time.

Fortunately when I press the `Erase Customization' button the second
time, the sample turns yellow as expected.  I am not sure this is a
bug, but it has happened with three different instances of `emacs -Q'.

Moreover, my mouse button presses normally work as expected.  For
example, when I press mouse button on the tick box for `Background',
it always works the first time.

In any event, the message for `Erase Customization' is OK:

    Un-customize all values in this buffer.

This is good news.

Unless fixed however, the name of the button `Reset to Saved' is
misleading, since it does not reset a face to a saved value after
un-customizing it.  This is bug six.

Moreover, it looks to me that `Set for Current Session' is not a
`Save' of any sort, either.  I have been unable to `Reset to' the
previously saved value after setting a value for a current session.
This is bug seven.

All in all, the interface is highly confusing.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

RE: Customize buttons that change user's custom file should askforconfirmation

[Drew Adams]

    Over all, on further
    investigation, the interface needs more work, not just some rewording.

    <...lots of great feedback...>

I, like some others, think that the Customize UI presents a great
opportunity for improvement ;-).

A lot of work has gone into the current design, and there are some good
aspects to it. Nevertheless, I think we could usefully put the design on the
table and talk about it from scratch, hashing over what we like and don't
like about it, and trying to come up with some improvements. Maybe the
result would be to decide to leave it as it is or to just tweak it a little,
but I do think it's worth spending time discussing it in detail - because I
think Customize could be more used and more useful than it is currently (for
both Lispers and non-Lispers - but that's another issue).

How about we open a discussion of how to improve the Customize UI - _after
the release_? To discuss it well and think carefully about it we'll need
some time. And now is not the best time.

Of course, Bob's feedback mainly involved bugs, and they can perhaps be
fixed now, for this release.

Re: Customize buttons that change user's custom file should askforconfirmation

[Richard Stallman]

    It would be good to have two different terms for the two different kinds of
    default value, so that we don't have to describe the context each time. One
    is the standard value for a user option (variable or face), where "standard"
    essentially means defined by defcustom or defface (IIUC). The other is the
    value a variable has in a buffer if there is no buffer-local value
    (setq-default).

The former is called "standard".  The latter is called "default".
I found a couple of places in cus-edit.el that said "default"
when they meant "standard", but the distinction was mostly maintained.

There is no need to reopen this issue.

RE: Customize buttons that change user's custom file shouldaskforconfirmation

[Drew Adams]

        It would be good to have two different terms for the two
        different kinds of
        default value, so that we don't have to describe the
        context each time. One
        is the standard value for a user option (variable or face),
        where "standard"
        essentially means defined by defcustom or defface (IIUC).
        The other is the
        value a variable has in a buffer if there is no buffer-local value
        (setq-default).

    The former is called "standard".  The latter is called "default".
    I found a couple of places in cus-edit.el that said "default"
    when they meant "standard", but the distinction was mostly maintained.

Right. Good.

So, to come back to the name of the button, can we agree on "Standard
Values"?

Re: Customize buttons that change user's custom file shouldaskforconfirmation

[Stefan Monnier]

> So, to come back to the name of the button, can we agree on "Standard
> Values"?

Since setting the vars to their saved value is called "Reset to Saved",
I'd say it should be called "Reset to Standard".

Maybe we don't want "Reset to", but then we shouldn't want it for "Reset to
Saved" either.


        Stefan

RE: Customize buttons that change user's custom file shouldaskforconfirmation

[Drew Adams]

    > So, to come back to the name of the button, can we agree on "Standard
    > Values"?

    Since setting the vars to their saved value is called "Reset to Saved",
    I'd say it should be called "Reset to Standard".

Yes, that would be clearer, now that the original pb with using "Reset to"
has been removed (by having save as a separate operation).

    Maybe we don't want "Reset to", but then we shouldn't want it
    for "Reset to Saved" either.

It helps to explicitly say Reset, IMO; it lets users know what to expect.
And yes, we should be consistent (Reset everywhere or nowhere).

Re: Customize buttons that change user's custom file shouldaskforconfirmation

[Miles Bader]

On Wed, 2 Feb 2005 11:02:50 -0800, Drew Adams <drew.adams@oracle.com> wrote:
>     > So, to come back to the name of the button, can we agree on "Standard
>     > Values"?
> 
>     Since setting the vars to their saved value is called "Reset to Saved",
>     I'd say it should be called "Reset to Standard".
> 
> Yes, that would be clearer, now that the original pb with using "Reset to"
> has been removed (by having save as a separate operation).

No, I think it's still bad:  "Reset" is too strong a word -- it
doesn't make it clear that a save step will subsequently be required
(especially for users used to the old behavior).  If there are other
bad uses, they should be changed too, of course.

How about "Get standard values", and "Get saved values"?

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Miles Bader" <snogglethorpe@gmail.com>

> No, I think it's still bad:  "Reset" is too strong a word -- it
> doesn't make it clear that a save step will subsequently be required
> (especially for users used to the old behavior).  If there are other
> bad uses, they should be changed too, of course.
>
> How about "Get standard values", and "Get saved values"?

Here is a little table trying to show what we actually want to set names on:

    Set:        Field => Current
    Save:      Field => Current, Saved

    Reset:     Current => Field
    Reset to Saved:     Saved => Field, Current (only if Saved)

    Erase Customization:    Standard => Field, Current, Saved

In this context "Reset to Saved" and "Get Saved" actually seem to me to say
too little instead. Maybe "Use Saved"?

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Miles Bader]

On Thu, 3 Feb 2005 07:58:00 +0100, Lennart Borgman
<lennart.borgman.073@student.lu.se> wrote:
> ----- Original Message -----
> >
> > How about "Get standard values", and "Get saved values"?
> 
> Here is a little table trying to show what we actually want to set names on:
...
> In this context "Reset to Saved" and "Get Saved" actually seem to me to say
> too little instead. Maybe "Use Saved"?

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

I think these names (and behaviors) make a _lot_ of sense; the
consistency is very appealing, and should help people learn the
meanings easily.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Kim F. Storm]

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
>
> I think these names (and behaviors) make a _lot_ of sense; the
> consistency is very appealing, and should help people learn the
> meanings easily.

The major problem IMHO with Customize is not the names for
the operations as such, but the way it differs from other
applications that the user may be accustomed to.

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

and consequently has fewer operations:

F => A           (Save, OK)
A => F           (Cancel)
D => A,F         (Clear All)  -> with confirmation


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.

IMO, we should consider the difference between F and C states as an
expert option.

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.

Also the user should be offered to save unsaved customizations when he
exits 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).



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.

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

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

Unless the user has previously used <Set> for any of the
variables on the page (so C != S), the effect is the same.
If C != S, it asks the user:
        Restore to last saved value (y/n)
and acts accordingly.

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

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

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

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

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Lennart Borgman]

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.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[David Kastrup]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> ----- 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.

But it should.  The previous "Erase Customization" is really a bad
surprise: it has permanent effects without asking for them.

One problem is that there is a difference between saving the default
value, and saving the fact that the default is not changed: when the
default value changes in later Emacs versions, an old saved default
will override the new one.

So it ought to be possible to really also save the "I'll take whatever
the default happens to be at any time" decision in addition to "I'll
take whatever the default is now".  And if one can save that decision,
it should also be displayed in some manner.

"Erase customization" accomplished some of that, but at the price of
being highly confusing.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "David Kastrup" <dak@gnu.org>

> > 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.
>
> But it should.  The previous "Erase Customization" is really a bad
> surprise: it has permanent effects without asking for them.
>
> One problem is that there is a difference between saving the default
> value, and saving the fact that the default is not changed: when the
> default value changes in later Emacs versions, an old saved default
> will override the new one.

Implementing "Erase" as Get Default+Save seems a bit more difficult to me
when a separate "Erase" button like now. Does not it require a new state for
the option field in the customization buffer? Keeping it as it is now, but
adding a clear question, is perhaps both more easy to implement and easy to
understand?

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

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

> 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.

As far as I can see this is essentially Miles suggestions (that means we
nearly agree already ;-) + combining Reset into one button. That might be a
good suggestion since it may look less complicated. There will also because
of the combination have to be a question (or menu) after this. This could be
worded so that it is more clear that Reset only resets the Field.

But still the "Erase" is missing (like in Miles suggestion). However can not
that naturally be a choice under Reset? There could then be some explanation
(and still a warning later). If we take this approach I think it can look
very nice:

  <Set All>  <Save All>  <Reset All ...>  <Close>

The three dots on Reset are supposed to indicates that there is some
question after clicking this button. This is a convention often used for
menus (but I do not know if it is used for buttons - though I would believe
it is easy to grasp if you know the menu convention). I think this still
meets Kim's concern that it should be close to common look and feel.

> 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.

I think all these actions should give some feedback!

RE: Customize buttons that change user's custom fileshouldaskforconfirmation

[Drew Adams]

    But still the "Erase" is missing (like in Miles suggestion).
    However can not
    that naturally be a choice under Reset? There could then be
    some explanation
    (and still a warning later).

I don't understand. We ~decided that Erase Customization was to be replaced
by Reset All to Standard plus Save. Are you arguing now to go back to Erase
Customization?

    > 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.

    I think all these actions should give some feedback!

My point was the _specific_ feedback - it should say not only what has been
done, but, in this case, it should also tell you about Set.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

> I don't understand. We ~decided that Erase Customization was to be
replaced
> by Reset All to Standard plus Save. Are you arguing now to go back to
Erase
> Customization?

If this can be done easily I have nothing against it, but I doubt it can.
"Standard" is perhaps not just a value? Someone (Kim?) pointed out that this
could mean give me the values that are default even if they change in the
future.

RE: Customize buttons that change user's customfileshouldaskforconfirmation

[Drew Adams]

    > I don't understand. We ~decided that Erase Customization was to be
    replaced
    > by Reset All to Standard plus Save. Are you arguing now to go back to
    Erase
    > Customization?

    If this can be done easily I have nothing against it, but I
    doubt it can.
    "Standard" is perhaps not just a value? Someone (Kim?) pointed
    out that this
    could mean give me the values that are default even if they
    change in the
    future.

We're talking only about the _UI_, not what's behind it (implementation). If
we can do it (now) with one button, why can't we do it with two buttons?

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

>     > I don't understand. We ~decided that Erase Customization was to be
>     replaced
>     > by Reset All to Standard plus Save. Are you arguing now to go back
to
>     Erase
>     > Customization?
>
>     If this can be done easily I have nothing against it, but I
>     doubt it can.
>     "Standard" is perhaps not just a value? Someone (Kim?) pointed
>     out that this
>     could mean give me the values that are default even if they
>     change in the
>     future.
>
> We're talking only about the _UI_, not what's behind it (implementation).
If
> we can do it (now) with one button, why can't we do it with two buttons?

Ok, I admit it can be done after choosing "Save" too. During the "Reset"
operation we have computed the "standard value" and we can compute it once
again during "Save" and if the value to save is equal to the "standard
value" then we could ask if the user wants to delete the customization. But
it is a bit obscure to me and hard to find.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Kim F. Storm]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

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

I don't like <Reset> as it doesn't "set" in the same sense as <Set>.

Miles suggested <Get>

Other possibilites are <Load> or <Reload> or <Undo>?

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

RE: Customize buttons that change user's custom fileshouldaskforconfirmation

[Drew Adams]

I'm not sure if we reached a consensus on this button-label question.

I said:

    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.

Kim said:

    I don't like <Reset> as it doesn't "set" in the same sense as <Set>.
    Miles suggested <Get>.

I agree. Here is what I would propose:

 Set All          (F => C)
 Save All         (F => C,S)
 Get All
   Standard       (D => F)
   Saved          (S => F)
   Current        (C => F)

1. Each button name includes "All". Likewise for menu-bar menu items.
2. The "resetting" actions only fill the edit field; they do not set the
current value.
3. The "resetting" actions are combined in a button menu (pulldown list).

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

> I agree. Here is what I would propose:
>
>  Set All          (F => C)
>  Save All         (F => C,S)
>  Get All
>    Standard       (D => F)
>    Saved          (S => F)
>    Current        (C => F)
>
> 1. Each button name includes "All". Likewise for menu-bar menu items.
> 2. The "resetting" actions only fill the edit field; they do not set the
> current value.
> 3. The "resetting" actions are combined in a button menu (pulldown list).

I like that though I still believe "Erase" is needed. Maybe "Erase All"? It
should of course ask for confirmation. (It does not belong under "Get All".)

RE: Customize buttons that change user's customfileshouldaskforconfirmation

[Drew Adams]

    I still believe "Erase" is needed. Maybe "Erase All"? It
    should of course ask for confirmation. (It does not belong
    under "Get All".)

By "Erase" do you mean the current Erase Customization functionality or
something else? I thought that we had more or less agreed to separate the
two functionalities that are mixed today in Erase Customization.

I gave reasons for splitting Erase Customization in two and reasons for
splitting the implicit Set from Get. What is the reason behind your
preference? Why do we "need" Erase?

RE: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Drew Adams]

If we do split Erase Customization in two: a) "Get All" > "Standard" plus b)
"Save All", then there is the question of how "Save All" should act wrt
values in the buffer that happen to be the same as the standard values.

Two possibilities:

1. Save is smart wrt `standard', recognizes equality between standard values
and values to be "saved", and reworks the user's custom file much as Erase
Customization does today.

2. Save is dumb, and always saves the values (edit fields) in the buffer to
the user's custom file.

It is the difference between a pointer and a copy:

The meaning of #1 is to maintain the standard value in future sessions.
Instead of a copy of the current `standard' value being saved, what would
really be saved is an indication that the `standard' value is to be used -
whatever the current standard value is at the time `custom-set-variables' is
executed. (We will need to fix some of the pbs already discussed, before
this will work correctly.)

The meaning of #2 is to take a snapshot of the current `standard' values
(those in the buffer) and save those value copies to the custom file.

When I made the suggestion to split Erase Customization, I had #1 in mind
(smart save, that is, no change to the Erase Customization behavior), but
now I think that this should perhaps be a user choice, possibly on a
case-by-case basis. A user might well somtimes want to Get the Standard
value and then save that value, whether or not it happens to stay the
`standard'.

For save operations on multiple options (Save All button and menu item), we
could provide radio buttons for the two choices in the buffer (or in the
menu). For save operations on a single option, we could provide two
different menu items.

OTOH, it might be confusing to combine these two notions under the name
"Save" - #2 is not at all a Save operation, in fact. With this
consideration, perhaps "Save" should mean save, and we should have a
separate button/item called something like "All Standard from Now On". Yes,
this is a return to Erase Customization, I guess.

What do others think?

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Robert J. Chassell]

   If we do split Erase Customization in two: a) "Get All" > "Standard" plus b)
   "Save All", then there is the question of how "Save All" should act wrt
   values in the buffer that happen to be the same as the standard values.

Clearly, when we tell Emacs to go to the default, it should do so.
That means deleting everything that is in a .emacs file and putting in
a commented-out statement that says

  ;; All customizations have been reset to the default.

It makes no sense to copy the default values from the Emacs sources to
the initialization file.

It does make sense to remind a person that he or she once had
customized Emacs, but decided to get rid of them.  (And presumably,
the old customizations will be saved in a back up file; that is a
benefit of rewriting the initialization file with just a comment in
it.)

   ... on a case-by-case basis. A user might well somtimes want to Get
   the Standard value and then save that value ...

That is a very different action than getting rid of all
customizations.  That involves deleting only the existing
initialization expression.  The other `setq', `custom-set-*', `defun',
etc. expressions remain.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

> If we do split Erase Customization in two: a) "Get All" > "Standard" plus
b)
> "Save All", then there is the question of how "Save All" should act wrt
> values in the buffer that happen to be the same as the standard values.
>
> Two possibilities:
>
> 1. Save is smart wrt `standard', recognizes equality between standard
values
> and values to be "saved", and reworks the user's custom file much as Erase
> Customization does today.
>
> 2. Save is dumb, and always saves the values (edit fields) in the buffer
to
> the user's custom file.
>
> It is the difference between a pointer and a copy:

I think the possibility in some way to Erase C should be kept. I said before
that I think 1 is a bit obscure, but maybe I was wrong there. If instead of
comparing the values a flag to tell that the standard value was fetched it
can be ok I guess.

Then there is the question whether the user should be asked when saving
whether to erase the entries in custom-file or not. I believe he/she should
be asked, but with only one question for multiple options. I believe this
will be more clear for the user without too much burden.

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Richard Stallman]

    If we do split Erase Customization in two: a) "Get All" > "Standard" plus
    
    "Save All", then there is the question of how "Save All" should act wrt
    values in the buffer that happen to be the same as the standard values.
    
    Two possibilities:
    
    1. Save is smart wrt `standard', recognizes equality between standard
    lues
    and values to be "saved", and reworks the user's custom file much as Erase
    Customization does today.

That is definitely the right way to do it.

If the "Get standard value" command puts the variable into a
state almost the same as never having been set, saving it
should get the right results.  This state would be almost the
same as the usual "set" state, except that it would record
a need to save the variable.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Robert J. Chassell]

   I like that though I still believe "Erase" is needed. Maybe "Erase All"? 

Since customize automatically rewrites your initialization file,
"Erase All" or `(customize-erase-all)' means converting your setqs to
the default values and deleting your defuns.

It means converting to an instance of Emacs such as you see when
invoking `emacs -Q'.

In such an Emacs, when you run a command such as 

    M-x customize-option RET baud-rate RET

it says `this option has been changed outside the customize buffer'. 

In this case, since this instance of Emacs lacks an initialization
file, this means value is set as the default in the distribution.

As far as I can see the phrase "Erase All" or the command
`customize-erase-all' is useless.  People will be better off starting
an instance of Emacs with `emacs -Q'.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Robert J. Chassell" <bob@rattlesnake.com>

> Since customize automatically rewrites your initialization file,
> "Erase All" or `(customize-erase-all)' means converting your setqs to
> the default values and deleting your defuns.

Is this a misunderstanding? Custom should just touch
(custom-set-variables...) and (custom-set-faces...) at the top level
(actually it only checks indentation but that is probably good enough) in
.emacs or custom-file.

"Erase All" should mean erase the entries in (custom-set-variables...) etc
for the options in the current customization buffer + reset fields and
current symbols' values.

Of course, we discussed other names for "Erase All" (and I forgot to choose
a better one here), "Standard Values", "Default Values" etc. What I wanted
to point out is that this (whatever it does not really fit under "Get All"
(since it does much more) and I pointed out earlier that it can not perhaps
always be done with Get+Save.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Robert J. Chassell]

In X Windows, when you move your mouse cursor over the button that
says `Save for Future Sessions' the help documentation should not only says

    Make your editing in this buffer take effect for future Emacs sessions.

as it does, but also

    This action automatically writes to your existing initialization file
    or creates a .emacs file if you lack one."

Otherwise, novices may be confused where custom automatically writes
and saves values.

This change is a bug that should be fixed during this feature freeze.

Other than discussion over the exact language to be used, this change
only involves adding two lines to the `custom-buffer-create-internal'
defun in   emacs/lisp/cus-edit.el
from

		 :help-echo "\
Make your editing in this buffer take effect for future Emacs sessions."

to
		 :help-echo "\
Make your editing in this buffer take effect for future Emacs sessions.
This action automatically writes to your existing initialization file
or creates a .emacs file if you lack one."

I used the phrase `existing initialization file' because some people
specify a different name for their .emacs file than `.emacs'.
However, the default for custom is to create a .emacs file
automatically.

More confusion:  I just discovered another bug.

I started an instance of Emacs with `emacs -Q' with a different user,
one that lacked an existing initialization file.  When I set an option
with `M-x customize-option RET baud-rate RET' a new .emacs file was
created, as expected.  However, I also received a message that said

    Saving settings from "emacs -q" would overwrite existing customizations

But since I had no existing customization, this message was wrong!

This is a second bug that should be fixed before the release.

As people keep observing, customize is a can of worms.  The more we
look, the more creepy, crawly things we see.  Worse, we are not going
fishing nor distributing them over a physical garden to improve it.

I once thought it was a good idea to offer a feature to write new
values to an initialization file.  I am not so sure now.

--
    Robert J. Chassell
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Robert J. Chassell" <bob@rattlesnake.com>

> More confusion:  I just discovered another bug.
>
> I started an instance of Emacs with `emacs -Q' with a different user,
> one that lacked an existing initialization file.  When I set an option
> with `M-x customize-option RET baud-rate RET' a new .emacs file was
> created, as expected.  However, I also received a message that said
>
>     Saving settings from "emacs -q" would overwrite existing
customizations
>
> But since I had no existing customization, this message was wrong!

It is worse than that - since .emacs was not run Custom can not really know
where to save and should just say so. Or, do you mean that Custom did
overwrite your .emacs?

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Robert J. Chassell]

    It is worse than that - since .emacs was not run Custom can not
    really know where to save and should just say so.  Or, do you mean
    that Custom did overwrite your .emacs?

No, this user has no .emacs file; this .emacs file was created
automatically.

The `custom-set-*' functions were designed to write automatically into
your initialization file, which is .emacs by default.  (You can change
it by setting `user-init-file' to another value.)

When you do not have an initialization file, the functions create a
.emacs file and write into it.

As of today's GNU Emacs CVS snapshot, Mon, 2005 Feb  7  14:18 UTC
GNU Emacs 21.3.50.51 (i686-pc-linux-gnu, GTK+ Version 2.4.14)
a .emacs file can contain either

    (setq next-line-add-newlines t)
or
    (custom-set-variables
     '(next-line-add-newlines t))

The effect is the the same.  

When the initialization file contains two or more variable setting
expressions, the last one takes precedence.

Mostly, people write `setq' statements in their .emacs file to
customize them, although I get the impression that a couple of people
here are depending more on the `custom-set-*' functions.

People are encouraged to write their own `setq' statements for
customization.  Otherwise, there computer will look very mysterious.
Emacs Lisp, at least its simple expressions, has the virtue of being
understandable by just about any one.

But some people use the `custom-set-*' functions since they do not yet
know how to use `setq' or because they do not understand new features,
like faces.

For example, I do not know how to set faces with `setq'.  So I use
`custom-set-faces' in two places in my .emacs file instead.  In one of
them, where I defined `bobs-w3-font-hook', I edited the expression
normally.  (That looks nice.... :)

In the other, where I set the `bold' face and others, I use the
`custom-set-faces' graphic user interface and let it write my .emacs
file automatically.  (The automatic writing produces ugly looking code
... :(

(Obviously, it would be pleasant and useful to fix ugly code
production; but that fix is not as important as others that need
doing.)

Clearly, the phrase "Erase All" should mean "Erase All
Customizations".  This means converting your `setq' and `custom-set-*'
expressions to their default values, deleting your defuns and anything
else in your initialization file.

Worse, since the Emacs provided by the distribution contains default
values, as it must, "Erase All" cannot actually mean erase everything,
but must mean "Reset All to Default Values".

So I do not think the word "Erase" should be part of the function name
or on any menu at all.  `Reset to Default' is much more accurate.
That phrase works both with the encouraged customization in which you
manually edit an initialization file and with customization in which a
value is written automatically into that initialization file.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that changeuser'scustomfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Robert J. Chassell" <bob@rattlesnake.com>



>     It is worse than that - since .emacs was not run Custom can not
>     really know where to save and should just say so.  Or, do you mean
>     that Custom did overwrite your .emacs?
>
> No, this user has no .emacs file; this .emacs file was created
> automatically.

I think this is a bug. Custom should just say that it can not save because
it do not know where if you started emacs with -Q.

Re: Customize buttons that changeuser'scustomfileshouldaskforconfirmation

[Richard Stallman]

    I think this is a bug. Custom should just say that it can not save because
    it do not know where if you started emacs with -Q.

Yes.  It could also omit the "Save" buttons and disable the "Save"
menu items.

Would someone like to implement that?

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Richard Stallman]

Do these changes fix the two problems?


*** cus-edit.el	30 Jan 2005 06:05:44 -0500	1.209
--- cus-edit.el	09 Feb 2005 02:59:47 -0500	
***************
***************
*** 1299,1305 ****
    (widget-create 'push-button
  		 :tag "Save for Future Sessions"
  		 :help-echo "\
! Make your editing in this buffer take effect for future Emacs sessions."
  		 :action (lambda (widget &optional event)
  			   (Custom-save)))
    (if custom-reset-button-menu
--- 1396,1403 ----
    (widget-create 'push-button
  		 :tag "Save for Future Sessions"
  		 :help-echo "\
! Make your editing in this buffer take effect for future Emacs sessions.
! This updates your Emacs initialization file or creates a new one one."
  		 :action (lambda (widget &optional event)
  			   (Custom-save)))
    (if custom-reset-button-menu
***************
*** 3720,3738 ****
  (defun custom-file ()
    "Return the file name for saving customizations."
    (or custom-file
!       (let ((user-init-file user-init-file)
! 	    (default-init-file
! 	      (if (eq system-type 'ms-dos) "~/_emacs" "~/.emacs")))
! 	(when (null user-init-file)
! 	  (if (or (file-exists-p default-init-file)
! 		  (and (eq system-type 'windows-nt)
! 		       (file-exists-p "~/_emacs")))
! 	      ;; Started with -q, i.e. the file containing
! 	      ;; Custom settings hasn't been read.  Saving
! 	      ;; settings there would overwrite other settings.
! 	      (error "Saving settings from \"emacs -q\" would overwrite existing customizations"))
! 	  (setq user-init-file default-init-file))
! 	user-init-file)))
  
  (defun custom-save-delete (symbol)
    "Visit `custom-file' and delete all calls to SYMBOL from it.
--- 3801,3811 ----
  (defun custom-file ()
    "Return the file name for saving customizations."
    (or custom-file
!       user-init-file
!       ;; Started with -q, i.e. the file containing
!       ;; Custom settings hasn't been read.  Saving
!       ;; settings there would overwrite other settings.
!       (error "Saving settings is not allowed in \"emacs -q\"")))
  
  (defun custom-save-delete (symbol)
    "Visit `custom-file' and delete all calls to SYMBOL from it.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Robert J. Chassell]

    Do these changes fix the two problems?

This works fine for me, except for a typo,
two instances of the word `one'.

    ! This updates your Emacs initialization file or creates a new one one."

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that change user's customfiles

[Robert J. Chassell]

In X Windows, when you move your mouse cursor over the button that
says `Save for Future Sessions' the help documentation should not only say

    Make your editing in this buffer take effect for future Emacs sessions.

as it does, but also say that

    This action automatically writes to your existing initialization file
    or creates a .emacs file if you lack one."

Otherwise, novices may be confused where custom automatically writes
and saves values.

This change is a bug that should be fixed during this feature freeze.

Other than discussion over the exact language to be used, this change
only involves adding two lines to the `custom-buffer-create-internal'
defun in   emacs/lisp/cus-edit.el
from

		 :help-echo "\
Make your editing in this buffer take effect for future Emacs sessions."

to
		 :help-echo "\
Make your editing in this buffer take effect for future Emacs sessions.
This action automatically writes to your existing initialization file
or creates a .emacs file if you lack one."

I used the phrase `existing initialization file' because some people
specify a different name for their .emacs file than `.emacs'.
However, the default for custom is to create a .emacs file
automatically.

More confusion:  I just discovered another bug.

I started an instance of Emacs with `emacs -Q' with a different user,
one that lacked an existing initialization file.  When I set an option
with `M-x customize-option RET baud-rate RET' a new .emacs file was
created, as expected and as Emacs should.  

However, I also received a message that said

    Saving settings from "emacs -q" would overwrite existing customizations

But since I had no existing customization, this message was wrong!

This is a bug that should be fixed before the release.

As people keep observing, customize is a can of worms.  The more we
look, the more creepy, crawly things we see.  Worse, we are not going
fishing nor distributing them over a physical garden to improve it.

I thought customize was a good idea once.  I am not so sure now.

--
    Robert J. Chassell
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that change user's customfiles

[Robert J. Chassell]

My apologies; I did not mean to send a message twice.  When I fetched
mail, my earlier message had not appeared and I thought I had forgot
to send it.  Turns out I was being too quick.  :-(

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

     Set All          (F => C)
     Save All         (F => C,S)
     Get All
       Standard       (D => F)
       Saved          (S => F)
       Current        (C => F)

This is clean and symmetric, and I agree with the plan to replace
Erase Customizations with Get All Standard Values.  However, the
command Reset to Saved is a clean and useful command, and I think that
replacing it with Get All Saved Values would be a step backwards.

How to get the best of both worlds?  Perhaps like this:

     Set All          (F => C)
     Save All         (F => C,S)
     Get All
       Standard       (D => F,C)
       Saved          (S => F,C)
       Current        (C => F,C)

This means that the last two commands are equivalent to the two
existing Reset commands.  (C => F,C is equivalent to C => F, too.)
However, the Get All Standard Values command would be different from
the existing Erase Customizations command (which does D => F,C,S).

Another idea is this:

     Set All          (F => C)
     Save All         (F => C,S)
     Reset to Saved (S => F,C)
     Get All
       Standard       (D => F)
       Saved          (S => F)
       Current        (C => F)

What do people think?

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Robert J. Chassell]

   Another idea is this:

        Reset to Saved (S => F,C)

This interface is not necessary and is a bit confusing.  The following
interface wording is better:

        Set All          (F => C)
        Save All         (F => C,S)

        Get All that can be automatically written by custom-set-*

          Standard       (D => F,C)
          Saved          (S => F,C)
          Current        (C => F,C)


Presumably, `Set All' means `evaluate new values specified in your
initialization file, both those automatically written by custom-set-*
as well as those you have written manually, but do not write the new
initialization file'.

Presumably, `Save All' means simply `automatically write custom-set-*
values into your initialization file, write that file, and then
evaluate it'.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

RE: Customize buttons that change user's customfileshouldaskforconfirmation

[Drew Adams]

            Set All          (F => C)
            Save All         (F => C,S)

            Get All that can be automatically written by custom-set-*

What is the nuance here? Just what is _not_ being gotten (what values cannot
be automatically written by custom-set*)?

              Standard       (D => F,C)
              Saved          (S => F,C)
              Current        (C => F,C)


    Presumably, `Set All' means `evaluate new values specified in your
    initialization file, both those automatically written by custom-set-*
    as well as those you have written manually, but do not write the new
    initialization file'.

I don't understand this. Set All (F=>C) means set all current values (C) to
the values shown in the edit fields (F). What does this have to do with the
init file?

    Presumably, `Save All' means simply `automatically write custom-set-*
    values into your initialization file, write that file, and then
    evaluate it'.

I was with you up until the last clause, "and then evaluate it". I don't
believe that is the current behavior or what is expressed by F=>C,S (set
current values from edit fields and save edit fields to custom file).
Evaluating the custom file would do a lot more than F=>C, and I expect that
that would introduce unwanted behavior.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Robert J. Chassell]

   I don't understand this. Set All (F=>C) means set all current
   values (C) to the values shown in the edit fields (F). What does
   this have to do with the init file?

Everything is written to the init file (or files loaded from it); that
is where customization forms are evaluated.  So `Set All (F=>C)' means
to set in the init file those values changed by customize.  

Or are you suggesting that the form be evaluated in some place a user
cannot see?  I can understand doing that; but it makes it less likely
that the person will learn to write simple forms.  Customization is,
after all, an automatic expression writing and evaluating function.
Not only do people like to see what the Lisp expression looks like, we
want to encourage them to do so!  After all, that leads to hacking.

The customize automatic expression writing action is rather like the
(not very good) function that came with Calc mode more than a decade
ago and since been removed.  The difference is that the Calc mode
automatic expression writing function wrote `defun' expressions and
could handle anything you could put in a keyboard macro of the time;
the Customization functions write `custom-set-*' expressions instead.

       Presumably, `Save All' means simply `automatically write
       custom-set-* values into your initialization file, write that
       file, and then evaluate it'.

   I was with you up until the last clause, "and then evaluate it". 

Well, when you `Save for Future Sessions' the new value takes effect
right away.  The expression is evaluated.  At least, that is what
happens now.  (I just checked.)

So save `all' must mean that _all_ customizations are saved and also
evaluated.  That means saving and evaluating your .emacs file.

Perhaps the button should be reworded to `Set and Save All'.  That is
clearer to me; I prefer this wording.  But it takes more room.  The
help (or `tip') on the button or function should explain that saving
the init file also involves evaluating it, so the new valued become
effective, that is, they become set as well as saved.

Actually, the more I think about it, the more I like the rewording to
`Set and Save All' even if it is longer.  After all, you can set
values in your initialization file without saving it; and you can save
it without evaluating it.  You have led to a good point.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

RE: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Drew Adams]

       I don't understand this. Set All (F=>C) means set all current
       values (C) to the values shown in the edit fields (F). What does
       this have to do with the init file?

    Everything is written to the init file (or files loaded from it); that
    is where customization forms are evaluated.  So `Set All (F=>C)' means
    to set in the init file those values changed by customize.

I don't think so. I don't think that's what happens now, at least, for Set.
"Setting" something in the init file is really (automatically editing and)
_saving_ it. The term "set" refers today to setting the _current value_.

    Or are you suggesting that the form be evaluated in some place a user
    cannot see?  I can understand doing that; but it makes it less likely
    that the person will learn to write simple forms.  Customization is,
    after all, an automatic expression writing and evaluating function.
    Not only do people like to see what the Lisp expression looks like, we
    want to encourage them to do so!  After all, that leads to hacking.

See above. AFAIK, Set is not involved with custom-set* in any way; it simply
does F=>C.

    The customize automatic expression writing action is rather like the
    (not very good) function that came with Calc mode more than a decade
    ago and since been removed.  The difference is that the Calc mode
    automatic expression writing function wrote `defun' expressions and
    could handle anything you could put in a keyboard macro of the time;
    the Customization functions write `custom-set-*' expressions instead.

           Presumably, `Save All' means simply `automatically write
           custom-set-* values into your initialization file, write that
           file, and then evaluate it'.

       I was with you up until the last clause, "and then evaluate it".

    Well, when you `Save for Future Sessions' the new value takes effect
    right away.  The expression is evaluated.  At least, that is what
    happens now.  (I just checked.)

    So save `all' must mean that _all_ customizations are saved and also
    evaluated.  That means saving and evaluating your .emacs file.

    Perhaps the button should be reworded to `Set and Save All'.  That is
    clearer to me; I prefer this wording.  But it takes more room.  The
    help (or `tip') on the button or function should explain that saving
    the init file also involves evaluating it, so the new valued become
    effective, that is, they become set as well as saved.

Save does mean set and save, so, yes, the current value is updated to the
same value that is written to your custom file. That is not the same thing
as evaluating your entire .emacs file, however.

I personally think that "Save" is clear enough, but you are correct that the
semantics behind the button are set and save. The tooltip and doc string
could make that explicit, as you suggest.

    Actually, the more I think about it, the more I like the rewording to
    `Set and Save All' even if it is longer.  After all, you can set
    values in your initialization file without saving it; and you can save
    it without evaluating it.  You have led to a good point.

How can you save Customize settings without also setting their current
values (today)? And, again, changing a value in your init file is not what
is meant currently by "set"; "set" refers to setting the current values.

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Robert J. Chassell]

    ... the current value is updated to the same value that is written
    to your custom file. That is not the same thing as evaluating your
    entire .emacs file, however.

I am refering to `All'.  Clearly, individual settings should not
involve evaluating your entire .emacs file.

    How can you save Customize settings without also setting their
    current values (today)? And, again, changing a value in your init
    file is not what is meant currently by "set"; "set" refers to
    setting the current values.

Just by saving them:  for example, just now I changed my bold face
from 

     '(bold ((t (:background "DodgerBlue4" :foreground "PaleGreen"))))
to
     '(bold ((t (:background "DodgerBlue4" :foreground "Red"))))

and saved it.  No, I did not set it.  (The red foreground would look
ghastly if I did.  I am going to change the face back before I restart
this Emacs.)  So the new setting is saved but not set.

I am not sure whether the user interface for automatically writing
custom-set-faces expressions permits you to save without setting
immediately; but that is a different matter.  It is straight forward
to save any customization without setting it just then.

However, unlike Emacs Lisp expressions saved in regular libraries,
Emacs Lisp expressions used for customization are saved in your .emacs
file.  That file is automatically loaded each time you start a new
instance of Emacs.  So customized saving implies (eventual)
evaluation.  

If we do not offer a `Save for the future, but not for this session'
option for the automatic writing user interface, it might reduce
potential confusion just a little to say `Set and Save All' and
besides saving, set for current use as well as after the next start.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>     How can you save Customize settings without also setting their
>     current values (today)? And, again, changing a value in your init
>     file is not what is meant currently by "set"; "set" refers to
>     setting the current values.
>
> Just by saving them:  for example, just now I changed my bold face
> from 
>
>      '(bold ((t (:background "DodgerBlue4" :foreground "PaleGreen"))))
> to
>      '(bold ((t (:background "DodgerBlue4" :foreground "Red"))))
>
> and saved it.  No, I did not set it.  (The red foreground would look
> ghastly if I did.  I am going to change the face back before I restart
> this Emacs.)  So the new setting is saved but not set.

So you say that Customize has a "save" operation that does "F => S"?

To me, the only sensible save operation is "F => C,S".

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

RE: Customize buttons that changeuser'scustomfileshouldaskforconfirmation

[Drew Adams]

        ... the current value is updated to the same value that is written
        to your custom file. That is not the same thing as evaluating your
        entire .emacs file, however.

    I am refering to `All'.  Clearly, individual settings should not
    involve evaluating your entire .emacs file.

"All" refers, in Customize, to all options in the current Customize buffer.
Your .emacs can involve lots of other things. Your .emacs is not currently
eval'd when you do anything in Customize, AFAIK, and it would be a mistake
to reevaluate .emacs, IMO. You are correct, however, that Save in Customize
means Set and Save - that is, those particular options listed in the current
Customize buffer are both set and saved.

        How can you save Customize settings without also setting their
        current values (today)? And, again, changing a value in your init
        file is not what is meant currently by "set"; "set" refers to
        setting the current values.

    Just by saving them:  for example, just now I changed my bold face
    ... to '(bold ((t (:background "DodgerBlue4" :foreground "Red"))))

OK. You're talking about editing _.emacs_ and saving it (correct?). Within
_Customize_, there is no way to Save without also setting, IIUC - that is
what I meant.

    However, unlike Emacs Lisp expressions saved in regular libraries,
    Emacs Lisp expressions used for customization are saved in your .emacs
    file.  That file is automatically loaded each time you start a new
    instance of Emacs.  So customized saving implies (eventual)
    evaluation.

Yes, eval of .emacs occurs upon startup (only).

    If we do not offer a `Save for the future, but not for this session'
    option for the automatic writing user interface, it might reduce
    potential confusion just a little to say `Set and Save All' and
    besides saving, set for current use as well as after the next start.

That is the current (and proposed) behavior: Save (in Customize) means set
and save. I personally think that "Save" is sufficient as the name, but I
agree that all help for the button/menu item should explicitly mention that
it both _sets_ and saves.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>


>      Set All          (F => C)
>      Save All         (F => C,S)
>      Get All
>        Standard       (D => F)
>        Saved          (S => F)
>        Current        (C => F)
>
> This is clean and symmetric, and I agree with the plan to replace
> Erase Customizations with Get All Standard Values.  However, the
> command Reset to Saved is a clean and useful command, and I think that
> replacing it with Get All Saved Values would be a step backwards.
>
> How to get the best of both worlds?  Perhaps like this:
>
>      Set All          (F => C)
>      Save All         (F => C,S)
>      Get All
>        Standard       (D => F,C)
>        Saved          (S => F,C)
>        Current        (C => F,C)

I believe the logical structure Miles first suggested (essentially the first
one above) with the enhancement above with a single "Get All"-button is the
best. It gives the possibility to preview the values before setting them.

RE: Customize buttons that change user's customfileshouldaskforconfirmation

[Drew Adams]

    >      Set All          (F => C)
    >      Save All         (F => C,S)
    >      Get All
    >        Standard       (D => F)
    >        Saved          (S => F)
    >        Current        (C => F)
    >
    > This is clean and symmetric, and I agree with the plan to replace
    > Erase Customizations with Get All Standard Values.  However, the
    > command Reset to Saved is a clean and useful command, and I think that
    > replacing it with Get All Saved Values would be a step backwards.
    >
    > How to get the best of both worlds?  Perhaps like this:
    >
    >      Set All          (F => C)
    >      Save All         (F => C,S)
    >      Get All
    >        Standard       (D => F,C)
    >        Saved          (S => F,C)
    >        Current        (C => F,C)

    I believe the logical structure Miles first suggested
    (essentially the first
    one above) with the enhancement above with a single "Get
    All"-button is the
    best. It gives the possibility to preview the values before
    setting them.

I agree (obviously).

I could live with the second set of buttons, except that they all _set_ the
current value, so they should be called Set All *, which produces confusion
with F => C.

         Set All          (F => C)
         Save All         (F => C,S)
         Reset to Saved (S => F,C)
         Get All
           Standard       (D => F)
           Saved          (S => F)
           Current        (C => F)

No; I think we should avoid Reset to Saved.

First, because it uses the confusing term "Reset" (which means other things
in many preference editors). Second, it is simply Get All Saved followed by
Set All, which is just two clicks and is much clearer. I don't see the
disadvantage of the first group above. Why is F => C,S helpful/needed?

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Richard Stallman]

    I believe the logical structure Miles first suggested (essentially the first
    one above) with the enhancement above with a single "Get All"-button is the
    best. It gives the possibility to preview the values before setting them.

Yes, it does that.  However, it is also more cumbersome to use.
Perhaps we should ask the users which one they prefer.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I believe the logical structure Miles first suggested (essentially the first
>     one above) with the enhancement above with a single "Get All"-button is the
>     best. It gives the possibility to preview the values before setting them.
>
> Yes, it does that.  However, it is also more cumbersome to use.

The problem with "S => C,F" compared to "S => F" is that you may have
saved a set of parameters that does something stupid (e.g. select
black on black text for the default font).

Being able to load such values and edit them before saving them
is very useful.


I don't know if "S =>" imply that we actually read the values from the
custom-file (e.g. .emacs) or if it just restores the value that was
initially read from that file, or the last value that was written by
this emacs to that file.


If it implies reading from the file, this could be used to load
values from a diffent custom-file (to see what they are) before
actually using them.

> Perhaps we should ask the users which one they prefer.

I prefer "S => F" with a message in the echo area telling the
user to use "Set All" to apply the values.

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

RE: Customize buttons that change user's customfileshouldaskforconfirmation

[Drew Adams]

    >     I believe the logical structure Miles first suggested
    >     (essentially the first
    >     one above) with the enhancement above with a single "Get
    >     All"-button is the
    >     best. It gives the possibility to preview the values
    >     before setting them.
    >
    > Yes, it does that.  However, it is also more cumbersome to use.

    The problem with "S => C,F" compared to "S => F" is that you may have
    saved a set of parameters that does something stupid (e.g. select
    black on black text for the default font). Being able to load such
    values and edit them before saving them is very useful.

Yes, that is the reason. In addition, "S => F" is clearer (because simpler).

    I don't know if "S =>" imply that [1] we actually read the values from
the
    custom-file (e.g. .emacs) or if [2] it just restores the value that was
    initially read from that file, or [3] the last value that was written by
    this emacs to that file.

What is the difference between [1] and [3]? I believe that custom-set* is
read from your .emacs ([1] and [3], IIUC). I think [2] would be confusing
behavior: The `saved' value that the user has in his mind should always
correspond to the value that will result if Emacs is restarted (now). That
is, it should correspond to whatever value .emacs reestablishes (unless that
is a `standard' value).

    If it implies reading from the file, this could be used to load
    values from a diffent custom-file (to see what they are) before
    actually using them.

No way to do that has yet been proposed. S=>F means to get the values from
the  custom-set* in the user's .emacs (custom file). There is currently no
way to designate a different library to use as the source of `saved'
settings.

Instead of providing such a feature, I'd suggest that users should just
`M-:' the custom-set* expression of the custom-file in question. IOW, I
don't think we should provide a Customize feature to get the custom-set*
stuff from an arbitrary file. Users who want to do that should be capable of
evaling the custom-set* expression.

If you simply _load_ (e.g. load-library...) a different custom-file (which
is not the same as Get All Saved) sometime after startup, then the values
would of course get set, in addition to the edit fields being filled. In my
proposal, those settings would show up as "Set", precisely so that you can
distinguish them from values established during startup (which show up as
`saved' ("unchanged").

    > Perhaps we should ask the users which one they prefer.

    I prefer "S => F" with a message in the echo area telling the
    user to use "Set All" to apply the values.

Me too.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Kim F. Storm]

"Drew Adams" <drew.adams@oracle.com> writes:

>     I don't know if "S =>" imply that [1] we actually read the values from
> the
>     custom-file (e.g. .emacs) or if [2] it just restores the value that was
>     initially read from that file, or [3] the last value that was written by
>     this emacs to that file.
>
> What is the difference between [1] and [3]?

If custom-file is updated by another emacs instance, [1] != [3].

>     If it implies reading from the file, this could be used to load
>     values from a diffent custom-file (to see what they are) before
>     actually using them.
>
> No way to do that has yet been proposed. S=>F means to get the values from
> the  custom-set* in the user's .emacs (custom file). There is currently no
> way to designate a different library to use as the source of `saved'
> settings.


M-: (setq custom-file "X")
M-x customize
do some editing
save (into X)
M-: (setq custom-file "Y")
get (from ?)

Question is "from X" or "from Y"?

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

RE: Customize buttons that change user's customfileshouldaskforconfirmation

[Drew Adams]

    >     I don't know if "S =>" imply that [1] we actually read
    >     the values from the
    >     custom-file (e.g. .emacs) or if [2] it just restores the
    >     value that was
    >     initially read from that file, or [3] the last value that
    >     was written by this emacs to that file.
    >
    > What is the difference between [1] and [3]?

    If custom-file is updated by another emacs instance, [1] != [3].

Thanks. I didn't pay attention to the "this emacs".

Since we're dealing with a file (persistence), I would think that [1] would
be the best approach. (I don't know either what we do currently.)

    >     If it implies reading from the file, this could be used to load
    >     values from a diffent custom-file (to see what they are) before
    >     actually using them.
    >
    > No way to do that has yet been proposed. S=>F means to get
    > the values from
    > the  custom-set* in the user's .emacs (custom file). There is
    > currently no
    > way to designate a different library to use as the source of `saved'
    > settings.

    M-: (setq custom-file "X")
    M-x customize
    do some editing
    save (into X)
    M-: (setq custom-file "Y")
    get (from ?)

    Question is "from X" or "from Y"?

Good point. I would think it should be Y.

In any case, we should tell the user just what will happen (with a
dynamically defined tooltip? "Get values from file `Y'") and echo what did
actually happen with a message ("Values read from file `Y'").

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Luc Teirlinck]

       M-: (setq custom-file "X")
       M-x customize
       do some editing
       save (into X)
       M-: (setq custom-file "Y")
       get (from ?)

       Question is "from X" or "from Y"?

   Good point. I would think it should be Y.

Absolutely not. `(setq custom-file "Y")' means that you want Custom to
_write_ to Y.  If you want Y to be read you have to load Y.

By the way, loading a file with a second custom-set-variables form is
not something Custom currently expects you to do.  It will work fine
and can be useful, _if_ you know what you are doing.  Some packages
use several files with separate `custom-set-variables' forms.
But, if you do not know Custom really well, unexpected things may happen.

If you want Y to be your Custom file, write:

(setq custom-file "Y")
(load custom-file)

in your .emacs, as the docstring of `custom-file' recommends.

Sincerely,

Luc.

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

>        M-: (setq custom-file "X")
>        M-x customize
>        do some editing
>        save (into X)
>        M-: (setq custom-file "Y")
>        get (from ?)
>
>        Question is "from X" or "from Y"?
>
>    Good point. I would think it should be Y.
>
> Absolutely not. `(setq custom-file "Y")' means that you want Custom to
> _write_ to Y.  If you want Y to be read you have to load Y.
..
> (setq custom-file "Y")
> (load custom-file)

Is not this a bit of a contradiction? I would not say that the semantic is
really clear.

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Luc Teirlinck]

Lennart Borgman wrote:

   > Absolutely not. `(setq custom-file "Y")' means that you want Custom to
   > _write_ to Y.  If you want Y to be read you have to load Y.
   ..
   > (setq custom-file "Y")
   > (load custom-file)

   Is not this a bit of a contradiction? I would not say that the semantic is
   really clear.

I wrote:

   If you want Y to be your Custom file, write:

   (setq custom-file "Y")
   (load custom-file)

Note:  _If_ you want Y to be your Custom file, write:

Who knows what somebody just doing `M-: (setq custom-file "Y")' is
actually trying to do?  Whether it is going to have any effect or not
depends on whether any option is still going to be saved in Custom or
not.  If you set custom-file through Custom, it is going to have an
effect in a reliable way.  (Custom is going to write your current
saved Customizations into that file, but it is not going to read
anything from that file.)

Where is the contradiction?

Sincerely,

Luc.

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

>    > Absolutely not. `(setq custom-file "Y")' means that you want Custom
to
>    > _write_ to Y.  If you want Y to be read you have to load Y.
>    ..
>    > (setq custom-file "Y")
>    > (load custom-file)
..
> Where is the contradiction?

The suggested (load custom-file) looks like it means "this is where we read
from". Though there can of course be no clear contradiction without clear
semantics.

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Luc Teirlinck]

Lennart Borgman wrote:

   The suggested (load custom-file) looks like it means "this is where we read
   from".

(load "file")  _does_ means to load "file", that is to read from the file.

(setq custom-file "file") means that Custom should write its saved
values into "file".  Maybe you do not even want to start using "file"
as your permanent Custom file.  Maybe you just want a record of all
values you are "saving" to that file, but do not really want to save
in .emacs or your "real" custom-file.

Sincerely,

Luc.

Re: Customize buttons that changeuser'scustomfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

> Lennart Borgman wrote:
>
>    The suggested (load custom-file) looks like it means "this is where we
read
>    from".
>
> (load "file")  _does_ means to load "file", that is to read from the file.
>
> (setq custom-file "file") means that Custom should write its saved
> values into "file".

Yes, but the original issue was what semantic "get saved" should have in
Custom. Or did I misunderstand that? (setq custom-file "Y") together with
the common use of (load custom-file) gives at least me a feeling that many
would expect "get saved" to read from Y. But it is actually not defined now
of course.

Re: Customize buttons that changeuser'scustomfileshouldaskforconfirmation

[Luc Teirlinck]

Lennart Borgman wrote:

   Yes, but the original issue was what semantic "get saved" should have in
   Custom. Or did I misunderstand that?

Probably not.  But somehow, in all of this, I missed what was
supposedly wrong with saved-value.

Sincerely,

Luc.

Re: Customize buttons that changeuser'scustomfileshouldaskforconfirmation

[Luc Teirlinck]

To try to be more clear:

Lennart Borgman wrote:
   
   Or did I misunderstand that? (setq custom-file "Y") together with
   the common use of (load custom-file) gives at least me a feeling that many
   would expect "get saved" to read from Y.

I suggested to set:

(setq custom-file "Y")
(load custom-file)

_in your .emacs_.

But here we are discussing what happens if you change custom-file in
an already running Emacs session, after a custom-file has already been
loaded.  In that situation loading that _second_ Custom file (which
presumably is an empty file to be written into by the current Emacs)
does not make a lot of sense.  The main type of situation in which one
might actually want to change custom-file in a running Emacs is the
following.

Suppose you are using Emacs 21.4 and Emacs 22 comes out.

You now start 21.4 and set custom-file _using Custom_ (important) to
".emacs-custom-22.1.el" or similar.  If I remember well (I have
actually done such things, but a while ago) that file does _not_ need
to exist.  Now all your 21.4 customizations are copied in the newly
created 22.1 custom file, except for `custom-file', which gets
correctly updated.  You then write code in your .emacs to load
".emacs-custom-22.1.el" if the Emacs version is 22.1.  You start 22.1
and watch out for possible errors due to incompatibilities with 21.4.
Then you do M-x customize-changed RET 21.4.

   But it is actually not defined now of course.

Currently, Custom stores the SAVED value in the saved-value property.
The resulting behavior seems OK to me.

Sincerely,

Luc.

RE: Customize buttons thatchangeuser'scustomfileshouldaskforconfirmation

[Drew Adams]

    But here we are discussing what happens if you change custom-file in
    an already running Emacs session, after a custom-file has already been
    loaded.  In that situation loading that _second_ Custom file (which
    presumably is an empty file to be written into by the current Emacs)
    does not make a lot of sense.  The main type of situation in which one
    might actually want to change custom-file in a running Emacs is the
    following.

I believe that Kim started off this change-custom-file thread, in the
context of the question of S=>F. He mentioned that it might be useful to
have S=>F instead of only S=>C,F, in order to let you retrieve values from a
second custom file without loading that second file.

I think the thread has diverged from Kim's point, which is OK, but I'm not
sure that everyone is following it clearly.

Re: Customize buttons that changeuser'scustomfileshouldaskforconfirmation

[Luc Teirlinck]

>From my previous message:

  You now start 21.4 and set custom-file _using Custom_ (important) to
  ".emacs-custom-22.1.el" or similar.

You can alternatively copy the 21.4 file into the 22.1.el file, but
there might be other things in there that you do not want to copy.
You then have to first visit the 21.4 file, find the
`custom-set-{variables,faces} forms and set the region around it
before writing it to the new file, you have to set or manually edit
the custom-file entry anyway and so on.  So sometimes it is more
convenient to let Custom do all that work.

As a said before a second reason to change custom-file in a running
Emacs session is to save your current settings into a (usually newly
created) file _without_ wanting to save them in your "real" custom
file.  Again, there is no reason to load that file.  You want to write
into it, not read from it.

Sincerely,

Luc.

RE: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Drew Adams]

            >     If it implies reading from the file, this could
            >     be used to load values from a diffent custom-file
            >     (to see what they are) before actually using them.
            >
            > No way to do that has yet been proposed. S=>F means
            > to get the values from the  custom-set* in the user's
            > .emacs (custom file). There is currently no way to
            > designate a different library to use as the source of
            > `saved' settings.

           M-: (setq custom-file "X")
           M-x customize
           do some editing
           save (into X)
           M-: (setq custom-file "Y")
           get (from ?)

           Question is "from X" or "from Y"?

       Good point. I would think it should be Y.

    Absolutely not. `(setq custom-file "Y")' means that you want Custom to
    _write_ to Y.  If you want Y to be read you have to load Y...
    If you want Y to be your Custom file, write: (setq custom-file "Y")
    (load custom-file) in your .emacs, as the docstring of `custom-file'
    recommends.

The question was about "getting" values from a custom file without loading
that file. You are confirming, I guess, that there is no way to change
custom-file for purposes of get-but-do-not-load.

RE: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Drew Adams]

                >     If it implies reading from the file, this could
                >     be used to load values from a diffent custom-file
                >     (to see what they are) before actually using them.
                >
                > No way to do that has yet been proposed. S=>F means
                > to get the values from the  custom-set* in the user's
                > .emacs (custom file). There is currently no way to
                > designate a different library to use as the source of
                > `saved' settings.
        
               M-: (setq custom-file "X")
               M-x customize
               do some editing
               save (into X)
               M-: (setq custom-file "Y")
               get (from ?)
        
               Question is "from X" or "from Y"?
        
           Good point. I would think it should be Y.
        
        Absolutely not. `(setq custom-file "Y")' means that you 
        want Custom to
        _write_ to Y.  If you want Y to be read you have to load Y...
        If you want Y to be your Custom file, write: (setq custom-file "Y")
        (load custom-file) in your .emacs, as the docstring of 
        `custom-file' recommends.
    
    The question was about "getting" values from a custom file 
    without loading that file. You are confirming, I guess, that 
    there is no way to change custom-file for purposes of 
    get-but-do-not-load.  

  If instead of `M-: (setq custom-file "Y")' we set custom-file through
  Custom, then the up to date Custom Info is _immediately_ in Y, without
  having to save any further option.  (Because saving `custom-file'
  itself took care of things.)
  So if somebody _really_ wants to change Custom file during an emacs
  session (instead of from .emacs) the way to do it is through Custom.

Got it.

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Luc Teirlinck]

Drew Adams wrote:

   The question was about "getting" values from a custom file without loading
   that file. You are confirming, I guess, that there is no way to change
   custom-file for purposes of get-but-do-not-load.

Setting custom-file _during an Emacs session_ is usually with the
intent to write into it.  One even usually picks a non-existent file
and lets Custom create it.

I believe that if you regularly want to switch customizations during an
Emacs session, you _might_ be able to use "custom themes".  I have
never felt the need myself, so I do not know exactly how they work,
but if you are interested, you could take a look.

If one wants to make switching between sets of related customizations
within an emacs session easier, then the best way to do that seems to
be to implement features on top of the existing Custom package rather
than to try to reimplement fundamental parts of Custom.  _Maybe_ that
is what custom themes already do.

Sincerely,

Luc.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Luc Teirlinck]

>From my previous message:


	  M-: (setq custom-file "X")
	  M-x customize
	  do some editing
	  save (into X)
	  M-: (setq custom-file "Y")
	  get (from ?)

	  Question is "from X" or "from Y"?

      Good point. I would think it should be Y.

   Absolutely not. `(setq custom-file "Y")' means that you want Custom to
   _write_ to Y.  If you want Y to be read you have to load Y.

Well, it is a little bit more complex than that.  As long as you have
not saved any options through Custom since the `M-: (setq custom-file "Y")'
you should read from X, for the reason given above.  But once you save
new options through Custom, the up to date description of current options
is in Y, not in X.

Sincerely,

Luc.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Luc Teirlinck]

Drew Adams wrote:

       M-: (setq custom-file "X")
       M-x customize
       do some editing
       save (into X)
       M-: (setq custom-file "Y")
       get (from ?)

       Question is "from X" or "from Y"?

   Good point. I would think it should be Y.

If instead of `M-: (setq custom-file "Y")' we set custom-file through
Custom, then the up to date Custom Info is _immediately_ in Y, without
having to save any further option.  (Because saving `custom-file'
itself took care of things.)

So if somebody _really_ wants to change Custom file during an emacs
session (instead of from .emacs) the way to do it is through Custom.

Sincerely,

Luc.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Luc Teirlinck]

After all, I do not understand why Custom _needs_ to read custom-file
in the first place.  It _knows_ what it wrote into the
custom-set-variables form.  If you edit that form by hand and want
Custom to know about it, use C-M-x.

But I do not understand why we are having all these detailed long
discussions about Custom buttons _now_.

Following changes related to Custom are planned or being discussed:

1. Change Custom to be able to handle especially hooks, but also other
   listvars, to which elements can be added both by code and by the user.

2. Change set-variable to make it use :set functions.

3. Make Custom handle buffer-local values.

4. Maybe change the button structure.

5. Maybe make Custom handle mode-dependent variables.

6. _Maybe_ reimplement custom-file.

I believe we agreed that we should not do _any_ of this until after
the 22 release.  We will be trying to fix some current bugs that can
be fixed without non-trivial changes in Custom before the release.

Custom is not straightforward to change.  I do not understand why we
are currently trying to discuss (4) completely up to minor
implementation details.  The relatively most urgent of the above is
(1), because it is necessary to fix several fundamental bugs.

Implementation details concerning (4) will depend on how 1, 2 and 3
are implemented.  Clearly questions about how to handle custom-file
depend on whether or not we will decide to do (6) and if so how.

I believe that the proper time to discuss this in detail is when
somebody finds the time to implement it.

Sincerely,

Luc.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Richard Stallman]

    I don't know if "S =>" imply that we actually read the values from the
    custom-file (e.g. .emacs) or if it just restores the value that was
    initially read from that file, or the last value that was written by
    this emacs to that file.

Until you brought this up, I would probably have used the value that
was initially read from that file, unless some other has since been
saved in it.  However, rereading that part of the file could be
a useful feature as you pointed out:

    If it implies reading from the file, this could be used to load
    values from a diffent custom-file (to see what they are) before
    actually using them.


    Being able to load such values and edit them before saving them
    is very useful.

    I prefer "S => F" with a message in the echo area telling the
    user to use "Set All" to apply the values.

If users often want to examine these values before putting them into
effect, then the split-up could be useful.  But if users nearly always
want to Set these values, it would be just a nuisance to have to do so
with a separate operation.

Can we get any guidance on this question from other applications?

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

>     Being able to load such values and edit them before saving them
>     is very useful.
>
>     I prefer "S => F" with a message in the echo area telling the
>     user to use "Set All" to apply the values.
>
> If users often want to examine these values before putting them into
> effect, then the split-up could be useful.  But if users nearly always
> want to Set these values, it would be just a nuisance to have to do so
> with a separate operation.
>
> Can we get any guidance on this question from other applications?

I do not know of any application that distinguishes between Set and Save.
However all operations in "options dialouges" in MS Windows either operates
on the fields or Set+Saves all the field values in the dialouge. The
operations on the field could be "reset" (to value upon entry of the
dialouge, very common), browse for values (dir, files, fairly common),
choosing from a list (fairly common).

This suggests to me that the most intuitive operation would be "S => F".

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Robert J. Chassell]

A better user interface for the `Customize' feature would show the
current value of a variable or face, the previous and yet earlier
values when applicable, and the value in the distribution.  The value
should not only be listed, but in the case of faces, shown as samples,
as is done now.


        Current  Previous    Yet earlier    Distribution  
         value     value        value         default     
                                               value      
          (in     (from       (from                       
          init    earlier     an even                     
          file)    init       earlier                     
                   file)       init                       
                               file)                      
                                                          
                                                          
Thus, for Mark Ring Max, the buffer among other features might show:

                                                          
        Current  Previous    Yet earlier    Distribution 
         value     value        value         default    
                                                         
           32        24           20            16       

(The `previous' and `yet earlier' entries should be blank when you
have not made previous initializations or customizations.  In this
instance the `current value' is the same as the `distribution default
value'.)

Since the Customization buffer only provides customization for some
objects, namely variables and faces, and does not even write defuns
automatically, it should be renamed the `Partial Customization
buffer'.  

This way, no one would suggest that `Customize All' in a partial
customization buffer should mean `Customize only those items that are
set in this buffer; do not Customize All'.  In particular, novices
mislearn when they come to think that a feature's range is different
than it really is.

Even when a partial customization buffer shows only variables and
faces, no hooks, defuns or keymappings, it would help both novices and
experts to show history -- that is to show the current value in one's
.emacs or other initialization file, previous values from init file
back ups, and the default or standard distribution value (which you
get from `emacs -Q'),

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> A better user interface for the `Customize' feature would show the
> current value of a variable or face, the previous and yet earlier
> values when applicable, and the value in the distribution.  The value
> should not only be listed, but in the case of faces, shown as samples,
> as is done now.
>
>
>         Current  Previous    Yet earlier    Distribution  
>          value     value        value         default     
>                                                value      
>           (in     (from       (from                       
>           init    earlier     an even                     
>           file)    init       earlier                     
>                    file)       init                       
>                                file)                      
>                                                           

This is overkill - making the interface more complex for no good reason.

For a customize page with currently 15 values, your suggestion
would raise that to 60

And for a face with 10 attributes, your would show 40 attributes...


As far as I understand the current discussion on Customize, the aim
is to simplify the interface and make the behaviour more in line
with that of other applications.

Your suggestion goes in the opposite direction.  I vote against going
down this route!

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

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

	<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.

It could display the list of options that will be saved,
and ask for confirmation, much as Dired does when you operate
on marked files.

    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.

I'm not sure what you have in mind for this operation to do.
Could you say?

	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.

I wouldn't use the term "reset" for these.  I am not sure whether
the change from S => F,C into S => F is a good idea.

	I still believe "Erase" is needed. Maybe "Erase All"? It
	should of course ask for confirmation. (It does not belong
	under "Get All".)

    By "Erase" do you mean the current Erase Customization functionality or
    something else? I thought that we had more or less agreed to separate the
    two functionalities that are mixed today in Erase Customization.

Yes.

RE: Customize buttons that change user's customfileshouldaskforconfirmation

[Drew Adams]

    	<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.

    It could display the list of options that will be saved,
    and ask for confirmation, much as Dired does when you operate
    on marked files.

Yes, why not.

        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.

    I'm not sure what you have in mind for this operation to do.
    Could you say?

Clear All was from Kim's message:

        The <Clear All> button first asks the user for confirmation.
        If ok it does "D => F"  (does not update C or S).
        It then prints a message
           Remember to use <Set> or <Save> to activate/save the values.

IOW, it does Get Standard.

    	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.

    I wouldn't use the term "reset" for these.

Agreed. In a later mail (2/6), I proposed this (adopting Miles's suggestion
of Get):

         Set All          (F => C)
         Save All         (F => C,S)
         Get All
           Standard       (D => F)
           Saved          (S => F)
           Current        (C => F)

        1. Each button name includes "All".
           Likewise for menu-bar menu items.
        2. The "resetting" actions only fill the edit field;
           they do not set the current value.
        3. The "resetting" actions are combined in a button menu
           (pulldown list).

    I am not sure whether
    the change from S => F,C into S => F is a good idea.

Agreed. See proposal above.

    	I still believe "Erase" is needed. Maybe "Erase All"? It
    	should of course ask for confirmation. (It does not belong
    	under "Get All".)

        By "Erase" do you mean the current Erase Customization
        functionality or
        something else? I thought that we had more or less agreed
        to separate the
        two functionalities that are mixed today in Erase Customization.

    Yes.

See my other, "New tack" message today. Instead of removing things from the
custom file to remove customizations and return to standard values, why not
just add a declaration to custom-set-variables (at the _end_ of the file)
that the standard values should be used.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

    In contrast, most other applications only have these states:

    F * the field value
    A * the active (current/saved) value
    D * the default value
    ...

    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.

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.  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?

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

> 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.

I do not think that is a good solution because the customization buffer
might be a result of a search.

> 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.

It is an unusual behaviour I think. Maybe it is because it is tedious?

> 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.  If that were the only way to make values
> take effect, it would be a lot simpler than the current Custom
> facility.

It is rather common on w32 that there is an Apply command which does this.

> 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.

I miss the Set button. IMO opinion the names you propose makes it a bit more
difficult to have a Set button.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

    > 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.

    I do not think that is a good solution because the customization buffer
    might be a result of a search.

I don't understand "result of a search" or how that relates to the
issue.  Could you please spell out your agrument?

    > 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.

    It is an unusual behaviour I think. Maybe it is because it is tedious?

It was not tedious at all.  To confirm when exiting is no more work
than giving the "Save" command.

    > 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.

    I miss the Set button. IMO opinion the names you propose makes it a bit more
    difficult to have a Set button.

Eliminating that distinction is part of the idea I'm considering now.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

>     > 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.
>
>     I do not think that is a good solution because the customization
buffer
>     might be a result of a search.
>
> I don't understand "result of a search" or how that relates to the
> issue.  Could you please spell out your agrument?

Sorry, I was really unclear. I think Luc and Drew has explained this more
clearly. I was thinking of different options in the buffer beeing in
different state. You may not even know exactly what is in the customization
buffer.

>     > 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.
>
>     It is an unusual behaviour I think. Maybe it is because it is tedious?
>
> It was not tedious at all.  To confirm when exiting is no more work
> than giving the "Save" command.

I thought that every option would require confirmation. Someone brought up
the idea that this could look similar to dired so maybe it would not be so
much work for the user.


>     I miss the Set button. IMO opinion the names you propose makes it a
bit more
>     difficult to have a Set button.
>
> Eliminating that distinction is part of the idea I'm considering now.

Yes, I can see that. I just wanted to say that I disagree. As I pointed out
earlier beeing able to test is essential. (But there may be other solutions
to this, like option value history.)

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

Lennart Borgman wrote:

   I thought that every option would require confirmation.

You mean every whole-buffer button?  It would be really annoying if
just setting or saving an individual option would ask for confirmation.

Sincerely,

Luc.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

>    I thought that every option would require confirmation.
> 
> You mean every whole-buffer button?  It would be really annoying if
> just setting or saving an individual option would ask for confirmation.

Yes, that was the context.

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Luc Teirlinck]

Lennart Borgman wrote:

   >    I thought that every option would require confirmation.
   > 
   > You mean every whole-buffer button?  It would be really annoying if
   > just setting or saving an individual option would ask for confirmation.

   Yes, that was the context.

This is one of the proposed changes I do agree with.  I never use the
whole-buffer buttons, but after setting custom-file to a junk file
(this is one instance where setting custom-file in a running Emacs
_is_ useful), I noticed that it is way to easy to accidentally click
on these buttons or accidentally hit return with point accidentally on
them.  I believe that confirmation should be asked, dired style, with
a list of affected options.  This situation has existed for a long
time now, so I do not believe that it is imperative to do this before
the release and I believe that it is better to wait.

This is a clearly implementable and limited change if we would decide
to do it.  If we decide to do it after the release, then I believe
that there is no sense in discussing implementation details now.

Sincerely,

Luc.

RE: Customize buttons that change user's custom fileshouldaskforconfirmation

[Drew Adams]

        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.

RE: Customize buttons that change user's custom fileshouldaskforconfirmation

[Drew Adams]

I said:

    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.
    ...
    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 mispoke in the second paragraph quoted above. The global buttons (Save All
etc.) and the menu-bar menu should always apply globally (to everything in
the buffer), not to the currently selected options.

The current selection should be treated instead by a context-sensitive
menu - e.g., the mouse-3 menu. Another reason for moving the menu from the
State button to, for example, mouse-3 is this: The State-button menu is
fixed as local to a particular option; it cannot be used as a
context-sensitive menu that applies to the current selection (or the option
under the pointer, if there is no selection).

In sum:

 - Global buttons and the menu-bar menu apply to all options in the buffer.
Their item names include the word "All".

 - A context-sensitive menu (e.g. mouse-3) lets you mark and unmark options
and perform Save, Set etc. actions on the marked options. If no option is
marked, then the menu actions apply to the option under the mouse pointer
("current" option).

 - You can mark or unmark all options in a region. The context-sensitive
menu items Mark and Unmark apply to all options in the region.

 - If we have a context-sensitive menu (e.g. mouse-3), as described, we
should move all of the individual-option items from the State menu to the
context-sensitive menu.

We might want to use mouse-2 instead of mouse-3 to bring up the
context-sensitive menu. Mouse-3 is standard for such a menu in many
applications, but using it here means users would lose the normal mouse-3
functionality. Mouse-2 follows links and activates buttons in Customize, so
there should be no conflict with the menu: to use the c-s menu you just
position the pointer anywhere that is not on a button or a link.

However, if we did that, then we should not also have any pull-down menus
(e.g. State) that are activated by mouse-2, because it needs to be clear
whether the menu that appears applies to some fixed object (e.g. State) or
is the context-sensitive menu (which applies to the selection).

I personally think that mouse-3 would be a good choice for the c-s menu and
that the loss of mouse-3 editing functionality would not be missed in
Customize (I don't miss it in my version of Dired that has similar
functionality).

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

> In sum:
>
>  - Global buttons and the menu-bar menu apply to all options in the
buffer.
> Their item names include the word "All".
>
>  - A context-sensitive menu (e.g. mouse-3) lets you mark and unmark
options
> and perform Save, Set etc. actions on the marked options. If no option is
> marked, then the menu actions apply to the option under the mouse pointer
> ("current" option).

I any proposal of this kind I think it is important to give the possibility
to use only the keyboard. Some people do not want to use the mouse and some
simply can not use it.

Why not let the menu-bar menu have entries for working with the "current
option". The "current option" could be that where the point is. (I
implemented this kind of functionality in my proposal long ago for a
redressed Custom GUI.)

RE: Customize buttons that change user's customfileshouldaskforconfirmation

[Drew Adams]

    >  - A context-sensitive menu (e.g. mouse-3)

    I any proposal of this kind I think it is important to give the
    possibility to use only the keyboard. Some people do not want
    to use the mouse and some simply can not use it.

That's standard practice: there should be keyboard access to the same
functionality provided by the mouse - in particular, popup menus. I don't
know if that's the case generally with Emacs (I think not), but it is
standard in many apps these days. Some such mechanism is, I think, in fact
required for accessibility standards that apply to disabled people - e.g.
W3C WCAG (Web Content Accessibility Guidelines) Double-A recommendations.

    Why not let the menu-bar menu have entries for working with the "current
    option". The "current option" could be that where the point is. (I
    implemented this kind of functionality in my proposal long ago for a
    redressed Custom GUI.)

That's possible, but I don't think it's desirable.

That is not standard in any UI I'm familiar with. A context-sensitive menu
is usually associated with a mouse button, because you are generally using
the mouse to manipulate things associated with that context. This is the
practice nearly everywhere in MS Windows, for instance. For example, you are
doing things in a dialog box, and you use mouse-3 to open a menu for
manipulating something in the dialog box that is under the mouse pointer.
Users are very used to this behavior.

It is true that Emacs has a notion of point (cursor) that is separate from
the pointer location, so that such an operation as you describe can be
unambiguous without the mouse. Dired, for instance, has a menu-bar menu
(Immediate) that is largely for manipulating an individual file at point.

I nevertheless think that in most contexts (e.g. Customize) the position of
point is not a very useful (because not very obvious) indicator of the
current focus of action.

Also, if the context is to sometimes be a _set_ of options, then point is
not a sufficient context indicator. It is better to make the focus of action
obvious - e.g. using visible marks. Another possibility in this regard is,
as Richard suggested, to list the options to which an action will apply (a
la Dired asking if you want to delete these files).

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

>     Why not let the menu-bar menu have entries for working with the
"current
>     option". The "current option" could be that where the point is. (I
>     implemented this kind of functionality in my proposal long ago for a
>     redressed Custom GUI.)
>
> That's possible, but I don't think it's desirable.
>
> That is not standard in any UI I'm familiar with. A context-sensitive menu
> is usually associated with a mouse button, because you are generally using
> the mouse to manipulate things associated with that context. This is the
> practice nearly everywhere in MS Windows, for instance.

I do not think it is that clear. Options dialogs in MS Windows do not have a
menu at all. It is also quite common that menus operate on the current item
(for example in a mail program).

A problem is of course that it must be clear what item the menus operates
on. In case of the Custom GUI what I have done is to let the menus for the
current item include the name of the item.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

    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.

I think it will be less confusing and will lead to less error, because
it is simple and easy to predict.

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

It is restrictive only in the sense that there are fewer different
ways to set the same values.  That is what makes it simple.


The idea of having "selection" of options is a complication.  It won't
solve any of the problems, so I am not interested in it.  We will
not go there.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

Richard Stallman wrote:

   One possible solution for that is to discourage, or even get rid of,
   of the per-variable command button.

I use Custom extensively.  The per-variable command buttons are the
_only_ ones I use.  Getting rid of them would make Custom unusable in
as far as I am concerned.

   If there is only the whole-buffer Set and the whole-buffer Save,
   this confusion won't happen.

If there were no whole-buffer Set and Save functions, the confusion
would never happen.  But I would not go as far as to suggest
eliminating the whole-buffer buttons, even though I do not consider
them to be very useful.  Maybe we could provide warning messages if
people tried to use them.  But I believe that it is _obvious_ to
Custom users that if they want to operate on an entire buffer, they
have to be really careful.  I would guess that the whole-buffer
buttons are _very_ seldom used.  It is much safer and much more
convenient to set or save options one by one.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Kim F. Storm]

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

>                               I would guess that the whole-buffer
> buttons are _very_ seldom used.  It is much safer and much more
> convenient to set or save options one by one.

My "guess" is exactly the opposite...

Most often, I just customize a specific variable or face, so 
for me there really isn't any conceptual difference between 
a per-variable and whole-buffer action.  So I use the "whole-buffer"
action buttons at the top of the customize buffer.

And, when I actually do customize a group of variables, I usually want
to set/save all the variables that I changed, so again I use the
"whole-buffer" buttons.

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

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

Kim Storm wrote:

   Most often, I just customize a specific variable or face,

So do I.

   So I use the "whole-buffer" action buttons at the top of the
   customize buffer.

I personally do not see the need to go to the top of the buffer to do
that, if you have a button right next to you.  (In large Custom
buffers, the top is out of sight.)  I certainly do not want to do that
and go back and forth all the time if I want to try out several
settings for the same option.

And, on top of that, I do not see any reason to run the risk of
inadvertently doing things I am not even aware of.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

    I would guess that the whole-buffer
    buttons are _very_ seldom used.

We could poll the users and see.  If users generally use the
single-item button and not the whole-buffer buttons, I would
not mind simplifying things by eliminating the latter.

    Most often, I just customize a specific variable or face, so 
    for me there really isn't any conceptual difference between 
    a per-variable and whole-buffer action.  So I use the "whole-buffer"
    action buttons at the top of the customize buffer.

For that kind of usage, you could equally well use either interface.
So we could eliminate either one of the two.

    And, when I actually do customize a group of variables, I usually want
    to set/save all the variables that I changed, so again I use the
    "whole-buffer" buttons.

Here's a case of someone who really wants the whole-buffer buttons.

If the two of you can figure out what basic difference leads you to
prefer these different modes of use, we might learn something from
that.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Here's a case of someone who really wants the whole-buffer buttons.
>
> If the two of you can figure out what basic difference leads you to
> prefer these different modes of use, we might learn something from
> that.

Both of us seem to primarily customize one option at a time --
so it's mostly a matter of how far you have to move the mouse
to active that changes...

My main objection to the customize interface is the long babble
at the start of the buffer and the long text on the buttons.

IMO, this is VERY dissimilar to other applications, and sort of
indicates to the movice user that the Customize interface is very
different from and much more complex than what the user is familiar
with.

A simpler interface with a "one line" button bar (prefeably in
the header line when supported) like this

    [Set]  [Save]  [Load]  [Finish]

would be ideal IMO.

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

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> "Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:
>
>>
>>> A simpler interface with a "one line" button bar (prefeably in
>>> the header line when supported) like this
>>>
>>>     [Set]  [Save]  [Load]  [Finish]
>>>
>>> would be ideal IMO.
>>
>> Most other applications have the buttons at the bottom. The idea as far as I
>> understand it is to have the field and buttons ordered so that what is used
>> first comes first. This is both a visual ordering and a keyboard ordering.
>> You get used to press TAB to go to the button or field you need next. (I
>> think we should encourage keyboard use. Accessability and health.)
>
> The reason the header line is nice is that it will remain on the screen
> even when you scroll the customize window.  But of course, you cannot
> activate it with your mouse.
>
> But it would make sense if C-x C-s saved the settings, while C-c C-c
> just set them.

In that case it would be more intuitive if the buffer would get its
modification flag set for any changed options, was treated to the same
"`*Customize settings*' not saved" dialog as other unsaved buffers
when exiting Emacs, and we should have a button "don't save" (which
would then exempt the option from influencing the buffer modified flag
and from getting saved as long as the buffer remains intact) for
options.

That would enable options to be changed temporarily, it would make the
default of option changes permanent (like users are accustomed to),
but if one is unsure about a setting, one simply does not save the
option buffer, and then one will get reminded when exiting Emacs that
options (that are not marked "Don't save" explicitly) might get lost.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: Customize buttons that change user's custom fileshouldaskforconfirmation

[Drew Adams]

    The reason the header line is nice is that it will remain on
    the screen even when you scroll the customize window.

Yes.  Of course, the same operations are also available in the menu-bar
menu, which stays put like a header line.

    But of course, you cannot activate it with your mouse.

We could make the header line mouse-sensitive, as in Info.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Kim F. Storm]

"Drew Adams" <drew.adams@oracle.com> writes:

>
>     But of course, you cannot activate it with your mouse.
>
> We could make the header line mouse-sensitive, as in Info.
>

That was the intention -- I meant "keyboard" not "mouse".

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

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Lennart Borgman]

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

> >     But of course, you cannot activate it with your mouse.
> >
> > We could make the header line mouse-sensitive, as in Info.
> >
>
> That was the intention -- I meant "keyboard" not "mouse".

Hm. I never noticed this before, but from an accessability point of view I
think it is bad that the header line in Info can not be reached from the
keyboard. Should it not be possible to go there with TAB and S-TAB? Would
not that be consistent with the behaviour in major web browsers?

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

Kim Storm wrote:

   Both of us seem to primarily customize one option at a time --
   so it's mostly a matter of how far you have to move the mouse
   to active that changes...

We all seem to usually set one option at a time.  There is no need in
that case to have to worry about thirty other options in the buffer
which I do not want to set or save, but for which I might have changed
the widget value, just for information purposes, to see what choices I
have (this happens often with more complex "Value Menu" buttons).
Using the whole buffer buttons forces you to be very careful, and
there is no need for that.

   My main objection to the customize interface is the long babble
   at the start of the buffer and the long text on the buttons.

That is completely unrelated to single option or whole buffer buttons.

   But it would make sense if C-x C-s saved the settings, while C-c C-c
   just set them.

Neither that nor a header line address my concerns in the first
paragraph above.  When I want to set or save a single option, I do not
want a convenient way to accidentally set or save some of the other
thirty or so options in the buffer.  What I want is to not have to
worry about the thirty other options.

I believe that the single option buttons are definitely needed.  The
usefulness of the whole buffer buttons is much less clear to me.
Using the whole buffer buttons is dangerous.  We could either
eliminate them, print them only if the user chooses to have them
through a customizable option in the custom-buffer group that would be
off by default, make them print a warning or whatever.  There is no
need to decide on that now.  We can decide on such issues when we take
up this discussion again after Emacs 22 is out, depending on how soon
after that Emacs 23 would be released, even after 23 is released.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Kim F. Storm]

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

> Kim Storm wrote:
>
>    Both of us seem to primarily customize one option at a time --
>    so it's mostly a matter of how far you have to move the mouse
>    to active that changes...
>
> We all seem to usually set one option at a time.  There is no need in
> that case to have to worry about thirty other options in the buffer


IMHO, this is _expert_ behaviour.

I think that most novice users will very rarely mix and match setting
some options and saving others.

If he is satisfied with the current settings, he will save them ALL.

If accidentally, he saves some option which he forgot he had only set
and really didn't want to set, he can EASILY revert the change, either
in the same emacs run or next time he runs emacs.


Why don't we simply introduce a "customize-expert" option that is off
by default, but can be turned on when the user gains more experience.

When off, it can limit the features of the customize interface to 
those features most novice users will be familiar to from other
interfaces.

When on, customize can show you all the current features (and
perhaps more, if we think it may be useful).


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

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Lennart Borgman]

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

> Why don't we simply introduce a "customize-expert" option that is off
> by default, but can be turned on when the user gains more experience.
>
> When off, it can limit the features of the customize interface to
> those features most novice users will be familiar to from other
> interfaces.
>
> When on, customize can show you all the current features (and
> perhaps more, if we think it may be useful).

I second that. (Or, if I don't that is propably because my english makes me
misunderstand "second that" ;-).

I feel sorry to say that again, but I tried to work in that direction in my
proposal
earlier (the code on EmacsWiki). I did work a bit more on that, merging it
with the current CVS code, but I have not uploaded that. It is however by no
means finished. The idea has mainly been to hide part of the interface that
seems unusual. They should be turned on if the user wants them. Examples of
this are the state buttons. I also restructured the GUI a bit.

It seems easy to add the new ideas that we tend to more and more agree on.
But Luc has pointed out it we should leave it to next release. I tend to
agree, since I see new points are surfacing.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

Kim Storm wrote:

   IMHO, this is _expert_ behaviour.

   I think that most novice users will very rarely mix and match setting
   some options and saving others.

Rarely, but sometimes.  Why confuse them badly if they do?  Moreover,
it is not just setting and saving.  It is also about looking at
possibilities and saving.  Especially with the more complex "Value Menu"
buttons.

   If he is satisfied with the current settings, he will save them ALL.

But the problem is exactly that he may _not_ be satisfied with all the
current "settings" (widget values).  He may just have wanted to set
them, or even more likely, just has been looking at them.

   If accidentally, he saves some option which he forgot he had only set
   and really didn't want to set, he can EASILY revert the change, either
   in the same emacs run or next time he runs emacs.

Why force users to go to that trouble if it can easily be avoided?
Moreover, if you save options that you do not want, you do
not even know which one you saved.  The user will have to scan his
custom-set-variables or custom-set-faces forms.  We are supposedly
talking about a novice user.

   Why don't we simply introduce a "customize-expert" option that is off
   by default, but can be turned on when the user gains more experience.

I believe that we should introduce a "customize-expert" option, off by
default, and only enable the all whole buffer buttons if it is on.
Personally, I would not turn it on.  I do not come even remotely close
to being enough of a Custom expert to be able to handle the complexity
of whole button buffers.  I always am careful to set custom-file to a
junk file when I play with them.  (I never use them "for real".  Much
too dangerous.)

   When off, it can limit the features of the customize interface to 
   those features most novice users will be familiar to from other
   interfaces.

Custom _is_ not exactly like other interfaces and _can_ not be.  Other
interfaces are not trying to handle an underlying customization system
that is anywhere as complex and extensive as Emacs'.  The average
Custom buffer is a lot longer and contains a lot more options than the
average customization "page" (or whatever they call it).  The choices
you have for an individual option can be a lot more complex.  Complex
types like `choice' force a concept of a `widget' value.  Very
importantly, other interfaces do not have to deal with the tremendous
complexity of options that can be changed by _both_ the user and programs.

What makes the whole button buttons dangerous are, among others, the
concept of a separate widget value, the difference between Set and
Save, bugs in Custom, the length of Custom buffers, options changed
by programs behind the user's back, and user absent-mindedness.  We
are never going to be able to do something about the latter, even if
we do something about everything else, which would be highly
non-trivial and would involve removing present features, which people
actually use.

The concept of saving options one by one is not a difficult concept,
whether the user is used to it or not.  One should not equate "novice"
with "stupid".

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Kim F. Storm]

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

> Kim Storm wrote:

I wrote, you wrote, Lennart wrote, RMS wrote, bla bla bla :-)

Seriously, we seem to _completely_ disagree what an ordinary (novice) user
would expect from a customization interface.

My claim is that he is familiar with an interface where a page has:

 - N different options (N > 1)

 - an "Apply" button  which saves and activates the changes,
   but keep the page open.

 - an "Ok", "Save" or "Finish" button which saves and activates the
   changes, and closes the page

 - a "Cancel" button which closes the page without saving or activating.

 - a "Reset to Defaults" button which removes all user customizations
   and activates some "factory" determined set of defaults.


 - he may expect to see buttons which open sub-panels for customizing
   a related group of options, or does some specific action.


IMO, any significant deviation from that scheme is for _experts only_.

Specifically, no matter how useful it might be, an ordinary user does
not expect to see a "checkbox" or "save" button for each option, and
he will quickly be lost is a maze of tiny little passages.

>
>    IMHO, this is _expert_ behaviour.
>
>    I think that most novice users will very rarely mix and match setting
>    some options and saving others.
>
> Rarely, but sometimes.  Why confuse them badly if they do?  Moreover,
> it is not just setting and saving.  It is also about looking at
> possibilities and saving.  Especially with the more complex "Value Menu"
> buttons.

There is NOTHING confusing if you can only "save all options".

The confusion arises when you have the option to "set but not save"
some options, and later on you do "save" -- that will save all options
including those you only "set".

But that's not a big obstackle.  If the user has used "set", then
changes some more options, and hit "save", emacs could just warn
him that

    Warning: This will save parameters which you have previously
             set for this session only.  Continue?

If he doesn't like that (because he has been experimenting with
various settings), he can say "no", do "Cancel unsaved changes",
and redo the changes he actually wants to save.

Maybe not 100% satisfactory, but there's nothing strange about it.


>
>    If he is satisfied with the current settings, he will save them ALL.
>
> But the problem is exactly that he may _not_ be satisfied with all the
> current "settings" (widget values).  He may just have wanted to set
> them, or even more likely, just has been looking at them.

I don't think this is _typical_ usage.

Suppose the user is playing with some feature, e.g. ido-mode, which
has many options.  He tries to "Set" some parameters to see the
effect.

If he doesn't like the effect, he will "Reset" to set it back to what
it was.

If he likes the effect, he should "Save" before starting to play
with the next option.  If he doesn't -- well, he will quickly
learn that is the proper thing to do if he is playing with things.


For this specific purpose, it might be useful (and not too obscure) if
each parameter had a single "Undo" button which could be used to reset
that specific parameter to the last saved value.  But I doubt it will
be used much.

>
>    If accidentally, he saves some option which he forgot he had only set
>    and really didn't want to set, he can EASILY revert the change, either
>    in the same emacs run or next time he runs emacs.
>
> Why force users to go to that trouble if it can easily be avoided?
> Moreover, if you save options that you do not want, you do
> not even know which one you saved.  The user will have to scan his
> custom-set-variables or custom-set-faces forms.  We are supposedly
> talking about a novice user.

Again, you expect a specific user behaviour -- which I think is uncommon.

>
>    Why don't we simply introduce a "customize-expert" option that is off
>    by default, but can be turned on when the user gains more experience.
>
> I believe that we should introduce a "customize-expert" option, off by
> default, and only enable the all whole buffer buttons if it is on.

Amusing :-)

> Personally, I would not turn it on.  I do not come even remotely close
> to being enough of a Custom expert to be able to handle the complexity
> of whole button buffers.  I always am careful to set custom-file to a
> junk file when I play with them.  (I never use them "for real".  Much
> too dangerous.)

Really ?  

If customize is so dangerous, it should really be off-limits for
everybody...

But seriously, I bet a novice user can make greater disasters with a
few lines of bad Lisp in .emacs that he will ever do with Customize.

>
>    When off, it can limit the features of the customize interface to 
>    those features most novice users will be familiar to from other
>    interfaces.
>
> Custom _is_ not exactly like other interfaces and _can_ not be.  Other
> interfaces are not trying to handle an underlying customization system
> that is anywhere as complex and extensive as Emacs'.  

Huh?  

Just because some dialogue box in some other application is
written in C++ or java or a combination of HTML, javascript, and Perl
doesn't mean that the underlaying functionality isn't as complex
as emacs'.

If you think there is a problem here, it might be that customize is
still a "low-level" interface, giving you access to too much of
emacs' functionality in a "lispy" way.

>                                                       The average
> Custom buffer is a lot longer and contains a lot more options than the
> average customization "page" (or whatever they call it).  The choices
> you have for an individual option can be a lot more complex.  Complex
> types like `choice' force a concept of a `widget' value.  Very
> importantly, other interfaces do not have to deal with the tremendous
> complexity of options that can be changed by _both_ the user and programs.

In the applications I work with, customization is combination of
several different management interfaces, XML import/export of
configuration files, automatically generated configurations, and
factory installed customer specific configurations.  

Configuring Emacs isn't nearly as complex as that!!!

>
> What makes the whole button buttons dangerous are, among others, the
> concept of a separate widget value, the difference between Set and
> Save, bugs in Custom, the length of Custom buffers, 

That's a generic issue -- and we should improve that if we can -- it
has nothing to do with how to set/save values.

>                                                     options changed
> by programs behind the user's back, and user absent-mindedness.  We
> are never going to be able to do something about the latter, 

True.

>                                                              even if
> we do something about everything else, which would be highly
> non-trivial and would involve removing present features, which people
> actually use.

I don't suggest to remove anything -- just hide things that is confusing
to the novice user.

>
> The concept of saving options one by one is not a difficult concept,
> whether the user is used to it or not.  One should not equate "novice"
> with "stupid".

So why do you do that ?

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

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

Kim Storm wrote:

   The confusion arises when you have the option to "set but not save"
   some options, and later on you do "save" -- that will save all options
   including those you only "set".

No, you completely misunderstand.  Getting rid of the Save-Set
distinction would _in no way whatsoever_ make using whole buffer
buttons safe.  There are _tons_ of problems with them, some of which I
described in my previous posting.

   > But the problem is exactly that he may _not_ be satisfied with all the
   > current "settings" (widget values).  He may just have wanted to set
   > them, or even more likely, just has been looking at them.

   I don't think this is _typical_ usage.

   Suppose the user is playing with some feature, e.g. ido-mode, which
   has many options.  He tries to "Set" some parameters to see the
   effect.

   If he doesn't like the effect, he will "Reset" to set it back to what
   it was.

You completely misunderstand again.  I am talking about just _looking_
at items in a "Value Menu", not about setting anything.  When you
click on a choice of the Value Menu, the default value _for that choice_
appears in the widget and a separate docstring for that choice may
appear, which you may want to read.  You may _only_ have clicked on
that choice for information purposes.  If you are not careful and start
looking at another option, without first resetting the Value Menu to your
actual choice, and use the per buffer buttons, you may accidentally
save the widget value, even though you never wanted to save or even
set it.  The problem is that Custom buffers can be large, so if you want
to save a totally unrelated option, you may have forgotten about the
docs you were reading, which are _out of view_.

The whole buffer buttons make merely *looking* at the choices you
have, or wanting to read their docs, a dangerous activity.

   If customize is so dangerous, it should really be off-limits for
   everybody...

Customize is not too dangerous, the whole buffer buttons are too
dangerous.  They probably should indeed be off limits for everybody.
I suggest getting rid of them.

   > The concept of saving options one by one is not a difficult concept,
   > whether the user is used to it or not.  One should not equate "novice"
   > with "stupid".

   So why do you do that ?

I do _not_ claim that the average user is too stupid to use whole
buffer buttons.  I claim that the whole buffer buttons needlessly
force the user to be careful about the many options in the buffer he
is not interested in.  On the other hand, your main argument against
per option customization appears to be that the average user is too
stupid to grasp the mind-boggling concept of option by option
customization if he is not used to it.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

>From my previous message:

   You completely misunderstand again.  I am talking about just _looking_
   at items in a "Value Menu", not about setting anything.

Well actually I said:

   He may just have wanted to set them, or even more likely, just has
   been looking at them.

So I did talk about "setting" _in addition_ to looking at the choices,
without setting anything.  But the point remains that just looking at
the possible choices for an option, without setting anything, poses a
danger if the whole buffer buttons are used, as I explained.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

> So I did talk about "setting" _in addition_ to looking at the choices,
> without setting anything.  But the point remains that just looking at
> the possible choices for an option, without setting anything, poses a
> danger if the whole buffer buttons are used, as I explained.

I agree with your points, but is not this the case with most options
dialoges? I myself have often found that I have lost track of what I am
doing in those dialoges in other applications. To be sure to avoid trouble I
then hit Cancel and start it over again. I guess many users do like that.

I think this habit is useful and I believe it will carry over to Emacs as
well if the options dialog is sufficiently similar to those found in other
applications. And they do have something similar to "whole buffer buttons".

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

The button I called RESET TO SAVED in my previous message could also
be called:  UNDO EDITS.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

I lost the CC's im my original reply to Lennart:

Lennart Borgman wrote:

   I agree with your points, but is not this the case with most options
   dialoges? I myself have often found that I have lost track of what I am
   doing in those dialoges in other applications. To be sure to avoid trouble I
   then hit Cancel and start it over again.

You mean that each time I have to set an option in Custom, I would
have to first enter a key sequence or hit a button in a header line to
cancel all previous edits, then I set my value as I do now, then I hit
another key sequence or click another button in the header line to
save it?  This does not appear to be a simplification of the current
situation to me.  I believe it would be very easy to occasionally
forget the first step.

How are you going to reset the value to standard, with the new design?
One definitely wants to reset a single option to standard, not
everything in the buffer.  Being able to easily set an option back to
standard is important to everybody, but especially to novices.  It
seem that you will still need the individual State buttons, even with
the new design.

It all looks like a completely unnecessary complication of things.
People are inevitably going to give up on the first step in the
tedious three step sequence and, inevitably, they are going to sooner
or later get burned by that.

If one really would want to get rid of the State buttons (which the
new design can not do), one could replace the individual State buttons
with individual rows of four buttons:

SAVE || RESET TO SAVED ||  RESET TO STANDARD || ADVANCED

where ADVANCED would contain the remainder of the current options
listed in State, that is, ADVANCED would still work like the current
STATE, but can be ignored unless needed.  RESET TO SAVED and RESET TO
STANDARD are an important rescue tool if you messed up.

The only argument I have yet seen against single option buttons is
that people are not used to it.  It does not take a gigantic mental
effort to get used to it, and it makes things a lot simpler and a lot
less error prone.

If Custom is hard to understand for other reasons, we could worry
about those.  But to me, it seems ridiculous to claim that single
option buttons are a difficult to grasp concept.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

I give a summary of my proposal to meet some of the objections
leveled against Customize.  I personally _only_ have problems with
the whole buffer buttons, but I have tried to take other people's
objections into account (which I understood to be that that the State
button implementation is too unintuitive):


Eliminate the "whole buffer" buttons
Eliminate the "whole buffer" state message.

Replace individual State buttons with individual rows of four buttons:

SAVE || UNDO EDITS ||  RESET TO STANDARD || ADVANCED

ADVANCED contains everything presently in State, except for the three
that are now separate buttons.  ADVANCED still works like State now,
but can be ignored if it is not needed.

Replace current state _messages_ with very short (maybe single word)
ones with longer help echo messages, as Drew proposed (but _maybe_ not
exactly the same ones as Drew proposed).


As none of this is scheduled to be implemented before the release, we
could discuss further details closer to implementation time, after the
release.  This discussion is getting very time consuming, and any
details will be forgotten by implementation time anyway.

Currently, getting 22 released seems more urgent.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Kim F. Storm]

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

> Currently, getting 22 released seems more urgent.

I agree 100% with _that_ :-)

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

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

      When you
    click on a choice of the Value Menu, the default value _for that choice_
    appears in the widget and a separate docstring for that choice may
    appear, which you may want to read.  You may _only_ have clicked on
    that choice for information purposes.

Regardless of your motive, this is specifying a value.  Users
understand, from using other setup utilities, that if you put in a
different value for an option, and then you say "Save changes", you
change the value.  If you don't want to do that, you had better either
put it back, or exit without saving.

We can help prevent accidents by making "Save new settings" show a
list of options whose values are about to be changed.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Kim F. Storm]

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

> You completely misunderstand again.  

I think I have understood your idea of "typical usage pattern",
I just disagree that it is "typical".

>                                      I am talking about just _looking_
> at items in a "Value Menu", not about setting anything.  

Ok, but if a novice user starts from option 1, changes it in various ways
to see what the possible values are, goes on to option 2, does the same,
and so on, until he reaches option 15, and then he sees a setting of that
option which he finds useful -- and then uses "Save" -- expecting that all
the other changes he made to options 1-14 will not be saved -- well
that's a really stupid user IMHO.

But that's how you claim most novice users will act -- so IMO you 
think they are stupid...

> The whole buffer buttons make merely *looking* at the choices you
> have, or wanting to read their docs, a dangerous activity.

As long as you don't use "Save", it's perfectly safe!

>    If customize is so dangerous, it should really be off-limits for
>    everybody...
>
> Customize is not too dangerous, the whole buffer buttons are too
> dangerous.  They probably should indeed be off limits for everybody.
> I suggest getting rid of them.

I disagree 100% --- most users will be familiar with the concept of
"saving all changes with one click".   Very few are familiar with a
concept that forces you to save each change individually.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

Kim Storm wrote:

   I think I have understood your idea of "typical usage pattern",

I do not believe so.  I use Custom extensively as a _browser_ and
_documentation tool_, but when I see an option I want to change and
save, I do so.  In my use of Custom as a browser and source of info, I
often click on "Value Menus".  I do not necessarily reclose them
because I still may want to look at them later and there is no need to
close them anyway.  Right now, I can browse in a relaxed fashion
without being careful.  I do not even need to worry about accidental
edits or anything.  If I want to save an option all I have to do is
check that one value and TAB RET.

After your change, whenever I want to change something, I will have to
worry about whatever else is in the buffer.  Actually, I will not,
because it would really be too cumbersome.  Unless there is an expert
option and it actually works, I would either use .emacs or put point
on the option and do `M-x customize-option RET', thereby avoiding the
trouble.

   As long as you don't use "Save", it's perfectly safe!

That is _exactly_ why I would never use the all buffer save.

   Very few are familiar with a concept that forces you to save each
   change individually.

So you really _do_ believe that this is a terribly difficult concept.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

    My claim is that he is familiar with an interface where a page has:

     - N different options (N > 1)

     - an "Apply" button  which saves and activates the changes,
       but keep the page open.

     - an "Ok", "Save" or "Finish" button which saves and activates the
       changes, and closes the page

     - a "Cancel" button which closes the page without saving or activating.

     - a "Reset to Defaults" button which removes all user customizations
       and activates some "factory" determined set of defaults.

I would like to move Customize in this direction.
At least the default style of Customize.

I don't mind if experts can customize it and make it do
something different.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>
To: "Kim F. Storm" <storm@cua.dk>


>     My claim is that he is familiar with an interface where a page has:
>
>      - N different options (N > 1)
>
>      - an "Apply" button  which saves and activates the changes,
>        but keep the page open.
>
>      - an "Ok", "Save" or "Finish" button which saves and activates the
>        changes, and closes the page
>
>      - a "Cancel" button which closes the page without saving or
activating.
>
>      - a "Reset to Defaults" button which removes all user customizations
>        and activates some "factory" determined set of defaults.
>
> I would like to move Customize in this direction.
> At least the default style of Customize.
>
> I don't mind if experts can customize it and make it do
> something different.

I think this would be a good solution. Though the discussion is intensive I
see no big difficulties to satisfy the different views this way. The expert
vs novice options for the Custom GUI could look something like this:

- A way to set/save individual options. This seems to be the most wanted. It
should then be hidden by default (for the novices).

- Showing/hiding some information, like the states of the items in the
customization buffer. Some information that are in itself valuable should
probably be off by default to make the Custom GUI more simple and in line
with what most users are accustomed too. Exactly which info is perhaps
difficult to say. I think however the different pieces should be possible to
hide/show individually (but buffer global to make it simple). I also suggest
that hiding/showing should be in the menu bar menus so that it easy to
change it while viewing a certain customization buffer.

- A very valuable idea in the current Custom GUI that is not really used
today is the small customization button. This should be enhanced with
visible state colors so that the user can get a quick overview over the
state of different options in the customization buffer. (But I still believe
these buttons should be hidden by default).

- Maybe a global "Set" buffon to turn on for the experts. I think however
this is less useful.

- Maybe something that means really "erase all customization done by
Custom". And a set/save version of this. This should not be buffer local,
but should erase the (custom-set-variables ...) in .emacs and do the
necessary changes in the current values (and maybe tell the user to restart
Emacs). This is of course something for the novices and it might be better
to tell the user how to do it by hand (editing .emacs).

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

People can put in these Gnome style whole buffer buttons that Kim
proposed.  That is OK, I do not care.

But _why_ on earth does anybody want to _hide_ that small State button,
that barely takes any space?  How can this _confuse_ people?  There is
a help echo saying "Change the state of this item".  If the user is
not used to customize individual items, he can just ignore the button.
If the help echo is not clear enough, make it clearer.  (Also, the
names of some items when you activate the State button could be made
more self-explanatory.)

The names "novice" and "expert" are used in a very incorrect way.  The
difference we are talking about has _nothing_ to do with how long you
have been using Emacs or Custom.

The two kinds of users we are talking about are non-inquisitive users
and inquisitive users.  Non-inquisitive users will just ignore he
State button, like they ignore anything else they are not used to.
They will remain novices forever.  Novices at Custom, novices at
Emacs, novices at everything they use.  Inquisitive users will say
"Wow, interesting!  That is something new!  I never saw this in other
customization interfaces.  Let me try this out!."  Then they will play
with it, and realize that this is a _much_ better interface than the
Gnome one.  For instance, unlike the eternal novices, they will be
able to undo mistakes by setting individual options to current or
standard, which is often needed.  They will very quickly become
experts, not only at using Custom, but at using Emacs.

Please, do not impede inquisitiveness.  Do not put obstacles in the
way of people who are willing to learn new things, by hiding stuff
from them.

Definitely do not hide the individual state messages, although they
can be made into single word items with help echos.  This info is needed.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Kim F. Storm]

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

> People can put in these Gnome style whole buffer buttons that Kim
> proposed.  That is OK, I do not care.
>
> But _why_ on earth does anybody want to _hide_ that small State button,
> that barely takes any space?  How can this _confuse_ people?  

Because having _both_ is confusing and dangerous.

If a user can change some options without saving then (browsing in
your terms), then saves some individual options, and later uses the
global save button, he will lose!

If there is only one way to set things, such confusion will not arise.

> The names "novice" and "expert" are used in a very incorrect way.  The
> difference we are talking about has _nothing_ to do with how long you
> have been using Emacs or Custom.

>
> The two kinds of users we are talking about are non-inquisitive users
> and inquisitive users.  Non-inquisitive users will just ignore he
> State button, like they ignore anything else they are not used to.
> They will remain novices forever.  Novices at Custom, novices at
> Emacs, novices at everything they use.  Inquisitive users will say
> "Wow, interesting!  That is something new!  I never saw this in other
> customization interfaces.  Let me try this out!."  Then they will play
> with it, and realize that this is a _much_ better interface than the
> Gnome one.  For instance, unlike the eternal novices, they will be
> able to undo mistakes by setting individual options to current or
> standard, which is often needed.  They will very quickly become
> experts, not only at using Custom, but at using Emacs.

I agree on the principle, but I don't see how setting one or more
options as a time hinders browsing.  Of course, it is a little more
cumbersome to actually set an option if the users has modified several
other options just to see what they have to offer -- but users will
be familiar with that from other applications...

Maybe the "Customize" menu could have a simple check-box option for
"Show per-option action buttons".  The inquisitive emacs user will
surely find it :-)   

I agree that if a user enabled this, the global buttons should not be
shown.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

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

[Buttons, buttons, buttons]

Look, I am not participating in this discussion because it is not
relevant for Emacs-22.1.  We have spent enough time on it already.
The right way of resolving it will be to check in some variants, test
drive them, discuss them.  And checking anything in for design
questions right now is completely out of the question.

This is post-Emacs-22.1 material.  Resolving this question
satisfactorily means playing with code, and now is not the time for
it.  I also have ideas of my own about how to do this consistently,
but I won't argue them now: no point.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

   Look, I am not participating in this discussion because it is not
   relevant for Emacs-22.1.  We have spent enough time on it already.

I have _tried_ to tell that a couple of times much earlier in the
discussion.  But at a given moment, I felt that I _had_ to
participate, because it looked like decisions were about to been made.
So once this came up again after the 22 or even 23 release, people
could be told that a decision was already made some years ago and that
there was no point reopening it.

Sincerely,

Luc.

RE: Customize buttons that change user's custom fileshouldaskforconfirmation

[Drew Adams]

    Maybe the "Customize" menu could have a simple check-box option for
    "Show per-option action buttons".  The inquisitive emacs user will
    surely find it :-)

    I agree that if a user enabled this, the global buttons should not
    be shown.

This is a compromise that gives both approaches what they want. We should,
however, strive to adopt such a compromise only if there is a consensus that
there is (separate) value in having _each_ approach - not simply because we
can't seem to reach consensus on _which_ approach is best.

I doubt that we currently agree that both approaches are good (simple, safe,
etc.), and that which to use should just be a user choice (option). From the
current state of the discussion, it sounds more like each "side" thinks that
his side is the "simpler" and "safer" approach.

I agree with everyone else that no action should be taken now. In fact, the
remainder of the customize-design discussion should be postponed until after
22.1 is released. There is a lot that we could put on the table for
discussion regarding customize, and some of the issues are best discussed in
combination. I think we all have the same general goals, and our differences
probably reflect (mainly) different usage patterns or mutual
misunderstandings.

That is, I expect that we can in fact reach consensus on what is the best
approach, given sufficient time and discussion. Customize is complex, the
present UI provides lots of possibilities for a user, and the possibilities
of changing customize to improve it are innumerable. So, it's no wonder that
we haven't yet reached consensus - we haven't really explored the customize
design space much. And, as I mentioned once before, it is essential to get
input from Per, who understands the original design well - both the intent
and the howto.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

>From my previous message:

   They will very quickly become experts, not only at using Custom,
   but at using Emacs.

To avoid having this interpreted in a silly way: I meant that they
will quickly become experts because they are inquisitive and willing
to try out things.  (_Obviously_ not just because of using the single
buffer buttons).

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

    But the problem is exactly that he may _not_ be satisfied with all the
    current "settings" (widget values).  He may just have wanted to set
    them, or even more likely, just has been looking at them.

The arguments you are making are arguments for complexity.  That is
the wrong approach for designing a user interface to help beginners.
So please stop raising such arguments.

We need to design a simple interface that is easy for beginners to
understand, so that they are not afraid to use it.  This means
rejecting the goal that it should be able to do "whatever the user
might want to do".  We have to design it to do the most common things
in the most straightforward way.

So please stop making arguments about "but maybe the user only wants X".

      Other
    interfaces are not trying to handle an underlying customization system
    that is anywhere as complex and extensive as Emacs'.

This is no excuse for making it more complex than it has to be,
so please don't mention it.

							  The average
    Custom buffer is a lot longer and contains a lot more options than the
    average customization "page" (or whatever they call it).

If that is a real cause of difficulty, lets subdivide the groups more.

      The choices
    you have for an individual option can be a lot more complex.  Complex
    types like `choice' force a concept of a `widget' value.

What do you mean by a "widget" value?

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

Richard Stallman wrote:

   This means rejecting the goal that it should be able to do
   "whatever the user might want to do".

I was only talking about a user who wanted to look at the choices he
had in a Value Menu (and maybe read their docstrings), did not want to
save or set anything, and forgot to reset the Value Menu to his usual
choice, because he got distracted by looking at another option, which
he then saved (together with the wrong Value Menu value).

   What do you mean by a "widget" value?

The value that would be saved if one saves.  In my usage, these often
get changed to values I have no intention of setting or saving for two
reasons.  The first one is clicking on Value Menu buttons for
information purposes.  The second is making inadvertent edits in
various ways, say, by not holding down a control or meta key long
enough.  (I am clumsy, so this happens regularly.)  You do not even
realize you made these edits.  If I save an individual option, I
carefully check for typos before I save.  But carefully checking an
entire long buffer is cumbersome.

With the whole buffer buttons it is easy to save values which the user
does not even realize he edited.  From then on strange things happen.
The only way to figure out what is going on is to study the
`custom-set-variables' form in your .emacs.

   We need to design a simple interface that is easy for beginners to
   understand, so that they are not afraid to use it.

If Custom is redesigned to use only whole buffer buttons, then I will
be afraid to use it.  I would personally quit using it and customize
everything through Lisp.

One could print a warning message whenever clicking on the whole
buffer buttons would save more than one option and ask for
confirmation in that case.  That would be a bare minimum.  But once I
get warned, I have to figure out the problems and correct them before
I can save the option I want.  We could offer to undo all edits made
in the buffer, as Lennart suggested, but then I lose the edits I want
just as well as those I do not want.

All this complexity completely disappears if one uses per option buttons.

We all seem to agree that we nearly always want to save only one
option at a time.  So I do not see how designing an interface forcing
people to save an entire long buffer all at once, and hence be super
careful before saving anything, makes sense. 

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

    Why don't we simply introduce a "customize-expert" option that is off
    by default, but can be turned on when the user gains more experience.

It might be a good idea, if this allows us to disconnect the goals for
convenience for experts from the goals for simplicity for beginners.

RE: Customize buttons that change user's custom fileshouldaskforconfirmation

[Drew Adams]

        the whole-buffer buttons are _very_ seldom used.

    We could poll the users and see.  If users generally use the
    single-item button and not the whole-buffer buttons, I would
    not mind simplifying things by eliminating the latter.

For the poll - Like Luc, I use the single-item operation (on the State
menu). I generally only set or save one option at a time.

If we used a header line, as Kim suggested, then that would be as convenient
(close by) as the State menu for operating on a single option. But some way
of letting you know which options will be affected (e.g. popup list) should
be implemented for any global button or menu, as we have discussed.

As someone mentioned, if you want to operate on multiple options, you don't
want to repeat the set or save operation for each option independently. So,
if we _must_ choose between the two methods, the global button is more
general.

What is the reason that we must choose and not have both local and global
actions? Is it to simplify the UI? Getting rid of the buttons would simplify
the buffer; but getting rid of some of the State menu items would not
appreciably simplify the UI, IMO.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

    What is the reason that we must choose and not have both local and global
    actions? Is it to simplify the UI?

I am considering the idea of eliminating one of them in order to
simplify the interface.  It seems to be far too complex now.

RE: Customize buttons that change user's customfileshouldaskforconfirmation

[Drew Adams]

        What is the reason that we must choose and not have both
        local and global actions? Is it to simplify the UI?

    I am considering the idea of eliminating one of them in order to
    simplify the interface.  It seems to be far too complex now.

Then I repeat: "Getting rid of the buttons would simplify the buffer; but
getting rid of some of the State menu items would not appreciably simplify
the UI."

The advantage of the buttons is being able to act on multiple options at
once. Acting on multiple options is perhaps for "experts" only, however.

The disadvantage of the buttons is that their behavior can be complex and
error-prone, as Luc described well.

In sum, if you want to simplify the UI and make it easier and less
error-prone for novices (in particular), then keep the single-option menus
and get rid of the buttons.

If you do get rid of the buttons, will you also get rid of the equivalent
menu-bar menu items? If not, then no functionality will be lost. And all
discussions of the button problems (complexity, expert-only? etc.) can be
ported to the menu-bar menu. ;-)

Re: Customize buttons that change user's customfileshouldaskforconfirmation

[Luc Teirlinck]

Drew Adams wrote:

   If you do get rid of the buttons, will you also get rid of the equivalent
   menu-bar menu items?

(Meant are the whole buffer buttons, if I understood correctly.)

I believe that for consistency, the equivalent menu-bar items, as well
as the `C-x C-s' binding in Custom buffers, should be eliminated too.
They pose the same problems as the buttons.

We could keep buttons, menu-bar items and binding, as an advanced
"use at your own risk" option for people like Kim, who like them.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Luc Teirlinck]

Richard Stallman wrote:

   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.  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 like the _current_ Custom interface.  I believe that its _general
design_, including the button structure, is hard to improve on.  I
would leave it alone.  Of course, there are various bugs that need to
be fixed and various _details_ that can be improved.

Most of the more serious problems that Custom suffers from, several of
which I have pointed out, result from the fact that Custom makes
certain assumptions for its correct functioning that Emacs does not
adhere to (or does currently not adhere to).

The two main ones are:

1.  The value given in the defcustom is the standard Emacs default
    value as seen in `emacs -q'.

I believe that for this one, we agreed that we would make sure that
Emacs adhered much better to this than it currently does, ideally
completely.  We already started implementing this, although there
still is much to do.

2.  A variable defined by defcustom is reserved for the user.  Code
    never messes with it.  If code needs to add stuff to hooks or
    listvars, split those hooks or listvars into two, one program
    variable and one user variable.

Here I believe I understood that you considered this requirement to be
unacceptable.  Because of this, certain non-trivial parts of Custom
will have to be rewritten and even redesigned (at least in as far as
hooks and certain listvars are concerned) so that they no longer rely
on this assumption.  I believe this will be difficult enough.  I would
not try to redesign non broken parts of Custom.

Sincerely,

Luc.

Re: Customize buttons that change user's custom fileshouldaskforconfirmation

[Richard Stallman]

    I like the _current_ Custom interface.  I believe that its _general
    design_, including the button structure, is hard to improve on.

I can't argue with your taste, but there seems to be a lot of indication
that it is too complex and hard to understand for beginners.

Re: Customize buttons that change user's custom file shouldaskforconfirmation

[Richard Stallman]

I changed the name "Reset to Standard" because it did not fit the
action of that operation, which was and is to delete the existing
customizations.

You suggested changing the action so that it only sets the values.
I think that is a good idea.  For this altered operation, I think
"Reset to Standard" might be a good name.

    How about "Get standard values", and "Get saved values"?

That may be better.

Re: Customize buttons that change user's custom file should askforconfirmation

[Richard Stallman]

    There is one logical problem. Should this work just on the symbols in the
    current customization buffer or on all values?

All those commands operate only on the symbols in the current buffer.
This one should, too.

It might be desirable to have a command like this that operates
universally.  I think the place for it, if any, is in the menu bar.

Re: Customize buttons that change user's custom file should ask forconfirmation

[Miles Bader]

>     Instead of "Erase Customizations":
>     1) "Default Values" - resets to default (= installed) settings
>     2) "Save" - the existing button. It would update the custom
>        file to use the installed settings.
> 
> Does anyone object to this change?
> It seems to me that this would eliminate a
> potential cause of "user error" in Custom.

Not just potential: I've gotten screwed more than once by the existing
behavior.  I definitely think Drew's change is a good one.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: Customize buttons that change user's custom file should ask forconfirmation

[Richard Stallman]

    >     Instead of "Erase Customizations":
    >     1) "Default Values" - resets to default (= installed) settings
    >     2) "Save" - the existing button. It would update the custom
    >        file to use the installed settings.

There is a lot of support for this change.
Would someone like to implement it?

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Robert J. Chassell]

Customize is a can of worms.  But the worms can improve the garden if
handled rightly!

As others feared years ago, I now fear that some will come to depend
on their .emacs file being written automatically by Customize.  They
will lose or not gain an understanding of the technology.  This
applies especially to people who are not programmers and who do not
wish to become programmers.

Customize should always show what it is automatically writing, just as
menu items always show key strokes, so anyone can become more expert
and more efficient if he or she wants.

This does not force anyone to learn anything, but it makes that
learning easy.  The person faces a low hill rather than a steep
mountain.

For a single value, 

    `Set for Current Session'

should show in the value window the humanly readable version of what
is set, such as

    (custom-set-variables
     ;; ...
     '(baud-rate 38400)
     ;; ... )

which takes a minimum of four lines.  (The current interface requires
one line, but does not show the complete expression.)  This need for
extra lines is a problem that I do not think we can avoid.

The commentary should say, as it does now,

    you have set this option, but not saved it for future sessions.


For future sessions, for a single value, we should replace `Save for
Future Sessions' with the more accurate statement

    `Set and Save', 

write the four line expression in the value window, and say in the
commentary

    you have set this option and saved it in your initialization file

So you would see in your  *Customize Face: bold*  buffer

    (custom-set-faces
     ;; ...
     '(bold ((t (:background "DodgerBlue4" :foreground "PaleGreen"))))
     ;; ... )

and the same expression, with the other custimized faces, too, in your
.emacs file.

As for `All': when using the automatic writing feature for
customization, that only makes sense as both a set and a save.
Otherwise, novices might inadvertently come to think that you need to
start a new instance of Emacs to gain new customizations.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Customize is a can of worms.  But the worms can improve the garden
> if handled rightly!
>
> As others feared years ago, I now fear that some will come to depend
> on their .emacs file being written automatically by Customize.

So what?

> They will lose or not gain an understanding of the technology.

So what?

> This applies especially to people who are not programmers and who do
> not wish to become programmers.

I don't see why I should disregard their wishes.

> Customize should always show what it is automatically writing, just
> as menu items always show key strokes, so anyone can become more
> expert and more efficient if he or she wants.

I disagree very strongly.  Customize is more complicated than just a
few setq-default (we have setter functions and stuff), and so all you
can say is what custom-set-variable action is being taken.  And
anybody who wants or needs to know this for editing a .emacs file can
look right into the .emacs file.

> This does not force anyone to learn anything, but it makes that
> learning easy.

It is distracting for no good reason.  I think this as misguided as
the wish of a mechanic that no dashboard should conceil the
electronics of a car.  The whole point of the dashboard is making it
possible to focus on what you need for your daily tasks.  The purpose
of Customize is to channel the operations of the user into a
controlled subset that works.  It is a bad idea to suggest to the user
that he is gaining anything by tampering around himself: missing or
too many parens, additional or missing quoting and so on can render a
.emacs file completely inoperative.  The whole story is there in the
Emcas Lisp manual if you desire it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Stefan Monnier]

> should show in the value window the humanly readable version of what
> is set, such as

>     (custom-set-variables
>      ;; ...
>      '(baud-rate 38400)
>      ;; ... )

Whether we want to teach users or not, the above is a bad idea: it is not
good elisp code and noone should write such a thing by hand.  If Custom
wants to show "here's how you can do it by hand" it should show (setq
baud-rate 38400) or something like that (which happens to take only
one-line, by  the way).


        Stefan

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Robert J. Chassell]

    >     (custom-set-variables
    >      ;; ...
    >      '(baud-rate 38400)

   ... the above is a bad idea: it is not good elisp code ... 

I am not going to say it is good code.  (Your `setq' example is
better.)  Unfortunately, that is what is currently written
automatically in one's .emacs file.

Willy-nilly, that is an example of what people see now.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Customize is a can of worms.  But the worms can improve the garden if
> handled rightly!

I don't see how the changes you suggest can be seen as an improvement.
Quite the opposite.

IMO, the beauty of Customize is that it hides all the nitty gritty details
that no users (novices or experts) need to worry about.


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

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Robert J. Chassell]

   IMO, the beauty of Customize is that it hides all the nitty gritty
   details that no users (novices or experts) need to worry about.

Emacs describes itself as

    extensible, 
    customizable, 
    self-documenting, 
    real-time, 
    display.

Nowadays, few environments work just on a line, not on a
two-dimensional display, and few are so slow as to be non-real-time.
The real-time and display features are old.

I presume that most environments have enough built-in documentation. 

But not all environments are as readily extensible and customizable,
even now, a generation later.

For example, I do not know how to extend my Enlightenment window
manager as well as the SCWM window manager.  I know that I can; I just
do not know how to do so readily.

Being able to extend and customize _readily_ is key:  if it is not
easy for me to change characteristics that are not very important to
me, I won't.  I will suffer.  Or, to put the practice more positively,
I will adapt.

However, when it is important that I extend and customize and when it
is easy to extend and customize, I will.

That is why I dislike a car with a dashboard that never let's me see
anything; why I dislike car which requires my mechanic to purchase a
special device to find out what is going on.  

The information should be readily available.  And nowadays, with cheap
displays of a few lines, and with already existing computers, an
`Advanced' or `Mechanics' output has a very low incremental cost.

The key is to satisfy both novices and experts.  (That is why I talked
about an `Advanced' or `Mechanics' output for a car display; mostly,
you don't want it, unless you are an experienced driver or a
mechanic.)

Fortunately, with modern computers and computer displays, it is easier
(but not easy) to satisfy both novices and experts now than in the
past.  Provide a good default interface for novices and also a way for
that novice to become an expert without too much trouble.

Back in 1984, which is now more than 20 years ago, I used a software
program that enabled just this:  it was easy to use the mouse and the
(no longer produced) windowing system to mark and move text.  After I
got used to that, I then tried out the various keyboard commands and
learned those.  They were much faster.  It would have been easier for
me if the menu items had listed the keyboard strokes, as Emacs does,
but the menu did not.

The point is, I went from the easier to the harder, from those forms
of command which were easier to learn but which also wasted my time
(but not in comparison to the mechanical typewriter I had used
previously) to those forms of command which were harder to learn but
the most efficient the technology could provide.

In Emacs, the Customize user interface enables a person to avoid
having to learn to write

    (setq baud-rate 28800)

in his .emacs file, but it should make learning that easy.  After all,
after first writing it, the person may need to change the speed,
perhaps to 38400.

It turns out -- I know this from experience -- that editing an
existing value is often easier and quicker than reusing the Customize
interface.

For example, I found it easier and quicker to see in reality the
difference between "dodgerblue3" and "dodgerblue4" by changing the
number 3 to a 4 in my .emacs file than by changing that number with
the Customize user interface.  (Earlier, I picked "dodgerblue" by
looking at the sample provided by the Customize interface.)

Those who do not wish ever to program in Emacs Lisp should always use
the Customize user interface.  The option to move to a more efficient
user interface should be up to the person.  

In some cases, the cost of learning is higher than the expected
return.  I use the Customize user interface to first set a face.  I do
not understand faces and have not found it worth the effort to learn
about them.

Thus, creating a user interface is difficult.  Not only must it
satisfy expert programmers, like many of the people on this list, it
must satisfy novices and experts who do not know or have forgot.

Although I hardly ever use it, I think the menu interface is
excellent.  It enables you to move, if you wish, from mouse commands
to keystroke commands, and to move readily.  And it tells you some of
the commands that are available, which is useful, too, if you have
forgot or did not know of them.

That is why I think it is so important to create a program that
provides user interfaces for both novices and experts.  That is why
Customize should not only do its job, but make it easy for a person to
learn.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> That is why I dislike a car with a dashboard that never let's me see
> anything; why I dislike car which requires my mechanic to purchase a
> special device to find out what is going on.
>
> The information should be readily available.

You can look into .emacs.  The information is not encrypted, it is not
binary.

> In Emacs, the Customize user interface enables a person to avoid
> having to learn to write
>
>     (setq baud-rate 28800)
>
> in his .emacs file, but it should make learning that easy.  After all,
> after first writing it, the person may need to change the speed,
> perhaps to 38400.
>
> It turns out -- I know this from experience -- that editing an
> existing value is often easier and quicker than reusing the
> Customize interface.

Then edit the value.  The information is not encrypted, it is not
binary.  I have done so on occasion.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Richard Stallman]

    > The information should be readily available.

    You can look into .emacs.  The information is not encrypted, it is not
    binary.

It is a good idea for every program to help users find the internal
data that implements any particular customization.  But since all the
Customize data is together in .emacs, it would be enough to have
one button at the top of every Custom buffer that takes you to
.emacs and goes to the start of the Custom data.

RE: Customize buttons that change user'scustomfileshouldaskforconfirmation

[Drew Adams]

    The key is to satisfy both novices and experts....
    Provide a good default interface for novices and also a way for
    that novice to become an expert without too much trouble....
    That is why Customize should not only do its job, but make
    it easy for a person to learn.

I don't agree with some of the detailed proposals you've made - for example,
I agree with Kim that your history-of-values display would be overkill and
confusing.

However, I do agree that Customize should do these things, in order of
priority:

1. "Do its job", as you put it:

 - make it easy for anyone, including a non-Lisper, to customize options
 - provide an easy-to-use options browser

2. Facilitate learning more about Emacs - Lisp, in particular.

#1 is far more important than #2. #2 should never interfere with #1. In
particular, the UI should not be made more complex in order to promote #2.

But Customize should not act as an obstacle to understanding what's under
the hood - it should facilitate that learning, but not require it or impose
it. Your analogy with menu items that show corresponding key sequences is a
good one. Simple information bridges like that help users be more effective.

As I mentioned long ago, I think that simple links in Customize to a) the
current Lisp value of an option and b) the defining source code, as are
available in `C-h v', would be unobtrusive and quite helpful.