New tack for Customize

[Drew Adams]

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