emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Customize buttons that change user's customfileshouldaskforconfirmat


From: Drew Adams
Subject: RE: Customize buttons that change user's customfileshouldaskforconfirmation
Date: Fri, 11 Feb 2005 13:13:46 -0800

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]