Re: Customize buttons that change user'scustomfileshouldaskforconfirmation

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.

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

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

[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