RE: Customize buttons that change user's customfileshouldaskforconfirmation

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

[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's customfileshouldaskforconfirmation

[Drew Adams]

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

        Agreed. See proposal above.

    What does "proposal above" refer to?  I don't see anything
    that appears to relate to this.

My bad. I read what you wrote backward, I guess. The proposal I meant was my
proposal of 2/6/2005, which was also quoted in the mail you quote:

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

My reply to a different message also makes clear that I still think S => F
is preferable to S => 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?

However, there is a typo there also. The last line should have S => F,C
instead of F => S,C.

To be clear: I prefer not to have S => F,C (Reset to Saved), but to have
instead S => F (Get All Saved) followed by F => C (Set All). Sorry for the
confusion.

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

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

"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

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

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