RE: offer to save customizations on exit?

[Drew Adams]

    The analogy breaks down in two important ways:

    1) It makes sense to make temporary changes to your editing
       environment.  Making temporary changes to files has no obvious use.

    2) Whenever you customize an option, you have to decide if it should
       be temporary or permanent.  The two both require an explicit
       action, namely activating a button.  When you change a buffer you
       make no such explicit decision.

It's a rough analogy, not a homeomorphism ;-).

My guess is that for some kinds of customization, users will typically make
changes, set them for the current session, and try them out for a while
before saving (I know that's what I'll do). They might make several such
changes that modify related UI features, for instance. After trying the
changes for a while, it would be convenient to save them all or some of
them - or not. That possibility is already available, of course, via
`customize-customized', but 1) users might not be aware of that, and 2) it's
still convenient to be asked on quitting, in case one forgets.

    I don't want to be asked when I leave if I want to save the current
    value of case-fold-search or debug-on-error, which are two option I
    set often.

Good point.

How about letting users exclude certain options, via a "don't ask" list?
There could be such a list available by default. I agree that options like
debug-on-error are good candidates for such exclusion (by default). It might
also be helpful to be able to exclude entire groups of related options (e.g.
via keyword :group).

    But I think it would be a good idea to remove (or hide by default) the
    UI for making temporary changes.  It would make the UI simpler, and I
    think the trend is that way: To make options persistent by default.

I don't have a lot of experience using Customize, so you might be right. You
are certainly right that that is the approach usually taken elsewhere. A
priori, my thought is that it would be a hassle to have to re-edit and
resave options that I just wanted to try out for a while (to get them back
to the way they were before experimenting). I'd rather be able to just quit
my session, knowing that I hadn't messed anything up.

Also, to get more or less the effect of not having temporary changes, either
1) a user can reply "Yes to All" (one keystroke), or 2) the "don't-ask" list
variable could be made to recognize two special values, instead of a list of
options: `t', meaning "save all changes, without asking", and `nil', meaning
"save no changes, without asking".

And it might also be helpful to have an explicit "ask" list, for exceptions
to ask about when the "don't-ask" list is `t' or `nil'.

Also, I should have mentioned earlier that the proposed "ask-when-quitting"
behavior should be a user option (perhaps turned on by default): you should
be able to bypass it altogether, if you wish. This could be implemented by
having "don't ask" set to `t' (or `nil') and having "ask" set to `nil'.

On a subject related to your suggestion to do away with "set for current
session", I wonder about the distinction between _editing_ an option value
and _setting_ it for the current session. I assume that the state of
edited-but-not-yet-set exists because the UI otherwise cannot know when
editing is finished - is that right? We might consider making it somehow
more obvious that an edited value has not been set - I can imagine users
getting bit by this, not noticing the change in label saying that they have
edited but not yet set.

Finally, I think it would be ideal if _all_ changes to all user options
(variables with "*" starting their doc strings) were included in such a
scheme by default - have `set-variable' and even `setq' (for user options)
add to the customized-options list, at least when they are executed
interactively (`M-x', `M-:'). That would help make Customize play better
with the rest of Emacs. I'm sure that this opinion will be more
controversial, however. (A priori, my thought would be to even remove the
"at least when executed interactively", and see what problems might arise if
we tried to tie all changes of user options to the customized-options list.)

 - Drew