offer to save customizations on exit?

offer to save customizations on exit?

[Drew Adams]

Note: This message discusses a possible new feature, for after the release.
Any followups can be off-list.

Analogy A~B:

A. You visit several files, and modify some of their buffers. You hit `C-x
C-c'. Emacs asks whether you want to first save each or all of the modified
files before exiting. You can reply to save all, save none, or save specific
files.

B. You customize several user options but you don't save the changes. You
hit `C-x C-c'. -- Ooops! your changes are gone, without warning. --

The analogy breaks down here. Emacs should ask you whether you want to first
save the changed-but-unsaved options.

You should be able to say "Yes to All", "No to All", or "Yes" or "No" to
each individual option. You should also be able to say "Visit" to go to a
Customize buffer to examine each option (see its current value, init value,
doc etc.).

IOW, a set of buffers visiting files is like an Emacs session "visiting"
your custom-file (.emacs). When you request to quit Emacs, you should have a
chance to act on any changes that have not yet been saved.

The analogy holds also wrt settings you change and then change back: If you
set an option and then set it back to the previous value, this is not
recognized as a no-op - just as for buffer changes without saving. If you do
`erase-customization', however, it is as if no changes had been made - just
as for undoing buffer changes.

Other opinions?

 - Drew

P.S. The code already exists to implement both checking for unsaved option
changes and visiting ("Visit") a customize buffer with those options - see
`customize-customized'. (The list of customized-but-not-saved options to be
visited could be first pruned of those for which the user has said "No".)

Re: offer to save customizations on exit?

[Per Abrahamsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> Other opinions?

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. 

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.

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.

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

Re: offer to save customizations on exit?

[Miles Bader]

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

It might be a good idea to make the interface for saving permanent
changes the "natural action" -- e.g., make the button for permanent
saves more obvious and easy to hit than the button for temporary
changes -- but please don't blindly follow such silly "trends" to
absurd conclusions.  The lack of any way to make temporary adjustments
to settings (in e.g., gnome apps) is _extremely_ annoying.

Gnome apparently feels that their purpose is to cater to newbies and
screw everybody else, so I suppose such a decision makes sense for
them, but Emacs has no (and shouldn't have any) such remit.  Emacs
must strike a balance between ease of use and functionality.

-Miles

Re: offer to save customizations on exit?

[Stefan Monnier]

> absurd conclusions.  The lack of any way to make temporary adjustments
> to settings (in e.g., gnome apps) is _extremely_ annoying.

> Gnome apparently feels that their purpose is to cater to newbies and
> screw everybody else, so I suppose such a decision makes sense for

Actually, it's when I'm a newbie at something that I need transient changes
the most, because it's the only way I can explore the actual effect of the
various config options without risking screwing up my config big time.


        Stefan

Re: offer to save customizations on exit?

[Richard Stallman]

    B. You customize several user options but you don't save the changes. You
    hit `C-x C-c'. -- Ooops! your changes are gone, without warning. --

I think this is a good idea.  It may be implementable with
a few lines of code.