From: "Drew Adams" <drew.adams@oracle.com>
Subject: New tack for Customize
Date: Tue, 8 Feb 2005 12:38:26 -0800 [thread overview]
Message-ID: <MEEKKIABFKKDFJMPIOEBOEGDCJAA.drew.adams@oracle.com> (raw)
Let's consider a new tack.
(See also my reply to RMS, Changed outside --> set, in Customize UI.)
Summary:
a) .emacs 1) establishes baseline (unchanged) option values and 2) can
specify the use of individual standard values.
b) All option changes after startup load are consider to "set" the
option.
c) We still have to fix the bugs.
Details:
1. We fix the bugs having to do with list variables that should not
be simply setq'd by Customize, as Luc has pointed out. We make
Customize somehow able to deal with such lists, or we remove them
from Customize, or we find some other solution.
2. We get rid of any changes to user options by vanilla Emacs after
the custom file (.emacs) is read. I'm thinking of
`user-mail-address' here. We manage to make `custom-set-variables'
always be the last thing executed upon startup.
3. The custom file and all that it loads are considered, for a given
user, to set the personal baseline, "unchanged" values of user
options it affects. No matter how they are set during the load
process, all option values set during startup load are marked
initially in Customize as unchanged, or "Custom File", values.
This corresponds to today's label "option has been set and saved".
These values are not necessarily the same as the `standard' (=
defcustom default) values. They calibrate Customize for a
particular user, defining the zero point against which all
subsequent changes are compared.
All option values that have not been changed by startup load are
marked in Customize as "Standard". So, after startup, Customize
has only "Custom File" values and "Standard" values. The former
were set during startup but are henceforth considered unchanged;
the latter were not set during startup.
4. This means that not all such baseline values are saved values in
the sense of being explicitly listed in `custom-set-variables'.
They are, however, all saved in the sense that the custom file and
the files it loads are _persistent_, and reloading them will
reestablish these personal baseline values.
5. Subsequent to startup load, _all_ changes to user options, no
matter how they are made, are marked in Customize as "Set".
6. In Customize, you can Get standard values or current values,
filling the edit fields. This does not also set the current value
- you must use Set to do that.
7. We might also make it possible to Get some baseline values - those
that are explicitly saved in `custom-set-variables'.
8. Getting other baseline values, that is, those that are set in
libraries loaded during startup, would not be possible generally.
Some of these might be resettable (changing not just the edit
field but also the current value) by reloading the appropriate
library, if we can devise a good way to keep track of the library
(e.g. `load-history'). It may not, however, be a good idea to even
try to get or reset such options.
9. If you try to Save a value, and that value is the same as the
`standard' value for the option, a dialog makes you choose whether
you want to save the edited value (= standard) or you want to
specify, in your custom file, that the `standard' value that is
current during startup should be used.
10. The latter corresponds more or less with today's Erase
Customization. If you choose it, however, no analysis of your
custom file is done, and no customization is removed from it.
Instead, an entry `(foo-option standard)' is added to
`custom-set-variables', which is at the end of the custom file.
Such an entry, when read on startup, is interpreted to DTRT: set
option `foo-option' to its standard value and mark its value in
Customize as "Standard" (not "Custom File").
This means that any customization of `foo-option' that you might
do somewhere during startup is overridden by your declaration to
use the standard value. And any future change to the standard
value (e.g. bug fix) is correctly picked up.
I think this approach would work and would be intuitive.
It might even provide some help wrt some of the more minor problems.
Library changes to user options, if always loaded during startup, will
simply be reflected as being part of the baseline (pseudo-saved)
personal values. In some (minor) cases, that might be a sufficient
temporary "fix". For example, that would reflect the `baud-rate'
option setting as a baseline value instead of reflecting it properly
as a `standard' value, but at least it would not show up as a user
change (either changed outside or set inside).
(Obviously, this is for after the release.)
next reply other threads:[~2005-02-08 20:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-08 20:38 Drew Adams [this message]
2005-02-10 6:02 ` New tack for Customize Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MEEKKIABFKKDFJMPIOEBOEGDCJAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).