all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: Customize buttons that change user'scustomfileshouldaskforconfirmation
@ 2005-02-10 17:25 Robert J. Chassell
  2005-02-10 18:25 ` David Kastrup
                   ` (2 more replies)
  0 siblings, 3 replies; 26+ messages in thread
From: Robert J. Chassell @ 2005-02-10 17:25 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 26+ messages in thread
* RE: Customize buttons that change user's customfileshouldaskforconfirmation
@ 2005-02-12 18:04 Drew Adams
  2005-02-12 18:45 ` Luc Teirlinck
  0 siblings, 1 reply; 26+ messages in thread
From: Drew Adams @ 2005-02-12 18:04 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Customize buttons that change user's customfileshouldaskforconfirmation
@ 2005-02-09 20:31 Robert J. Chassell
  2005-02-09 21:27 ` Customize buttons that change user'scustomfileshouldaskforconfirmation Drew Adams
  0 siblings, 1 reply; 26+ messages in thread
From: Robert J. Chassell @ 2005-02-09 20:31 UTC (permalink / raw)



   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

^ permalink raw reply	[flat|nested] 26+ messages in thread
* RE: Customize buttons that change user's customfileshouldaskforconfirmation
  2005-02-07  7:25 ` Customize buttons that change user's customfileshouldaskforconfirmation Lennart Borgman
@ 2005-02-07  7:34 Drew Adams
  2005-02-07 17:28 ` Customize buttons that change user'scustomfileshouldaskforconfirmation Drew Adams
  1 sibling, 1 reply; 26+ messages in thread
From: Drew Adams @ 2005-02-07  7:34 UTC (permalink / raw)


    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?

^ permalink raw reply	[flat|nested] 26+ messages in thread
* RE: Customize buttons that change user's custom fileshouldaskforconfirmation
@ 2005-02-07  5:32 Drew Adams
  2005-02-07  7:25 ` Customize buttons that change user's customfileshouldaskforconfirmation Lennart Borgman
  0 siblings, 1 reply; 26+ messages in thread
From: Drew Adams @ 2005-02-07  5:32 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2005-02-14  3:32 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-02-10 17:25 Customize buttons that change user'scustomfileshouldaskforconfirmation Robert J. Chassell
2005-02-10 18:25 ` David Kastrup
2005-02-10 19:01 ` Stefan Monnier
2005-02-10 22:49   ` Robert J. Chassell
2005-02-10 21:39 ` Kim F. Storm
2005-02-10 23:45   ` Robert J. Chassell
2005-02-11  0:54     ` David Kastrup
2005-02-12  8:38       ` Richard Stallman
2005-02-12 18:20     ` Drew Adams
  -- strict thread matches above, loose matches on Subject: below --
2005-02-12 18:04 Customize buttons that change user's customfileshouldaskforconfirmation Drew Adams
2005-02-12 18:45 ` Luc Teirlinck
2005-02-12 21:01   ` Customize buttons that change user'scustomfileshouldaskforconfirmation Lennart Borgman
2005-02-12 21:21     ` Luc Teirlinck
2005-02-12 21:28       ` Lennart Borgman
2005-02-12 21:42         ` Luc Teirlinck
2005-02-14  2:07   ` Drew Adams
2005-02-14  2:21     ` Drew Adams
2005-02-14  3:32     ` Luc Teirlinck
2005-02-09 20:31 Customize buttons that change user's customfileshouldaskforconfirmation Robert J. Chassell
2005-02-09 21:27 ` Customize buttons that change user'scustomfileshouldaskforconfirmation Drew Adams
2005-02-10 14:42   ` Robert J. Chassell
2005-02-10 15:20     ` Kim F. Storm
2005-02-07  7:34 Customize buttons that change user's customfileshouldaskforconfirmation Drew Adams
2005-02-07 17:28 ` Customize buttons that change user'scustomfileshouldaskforconfirmation Drew Adams
2005-02-07 20:23   ` Robert J. Chassell
2005-02-07 20:26   ` Lennart Borgman
2005-02-08 11:46     ` Richard Stallman
2005-02-07  5:32 Customize buttons that change user's custom fileshouldaskforconfirmation Drew Adams
2005-02-07  7:25 ` Customize buttons that change user's customfileshouldaskforconfirmation Lennart Borgman
2005-02-07 13:45   ` Robert J. Chassell
2005-02-07 16:46     ` Customize buttons that change user'scustomfileshouldaskforconfirmation Lennart Borgman
2005-02-07 14:15   ` Customize buttons that change user's customfileshouldaskforconfirmation Robert J. Chassell
2005-02-07 16:23     ` Customize buttons that change user'scustomfileshouldaskforconfirmation Lennart Borgman
2005-02-07 20:22       ` Robert J. Chassell

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.