bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Cameron Desautels]

[-- Attachment #1.1: Type: text/plain, Size: 452 bytes --]

Implements the following, as requested in `etc/TODO`:

** A function to check for customizable options that have been
   set but not saved, and ask the user whether to save them.
   This could go in kill-emacs-query-functions, to remind people
   to save their changes. If the user says yes, show them
   in a Custom buffer using customize-customized.

My copyright assignment info should be on file.

Cheers.

-- 
Cameron Desautels <camdez@gmail.com>

[-- Attachment #1.2: Type: text/html, Size: 686 bytes --]

[-- Attachment #2: 0001-Add-mechanism-to-prompt-about-unsaved-customizations.patch --]
[-- Type: application/octet-stream, Size: 3660 bytes --]

From dd192cd7c45f3e815b5a731420c5293d74c6075a Mon Sep 17 00:00:00 2001
From: Cameron Desautels <camdez@gmail.com>
Date: Tue, 9 Dec 2014 00:28:44 -0600
Subject: [PATCH] Add mechanism to prompt about unsaved customizations

- Requested in `etc/TODO'
- Suitable for use in `kill-emacs-query-functions'.
---
 etc/TODO         |  6 ------
 lisp/ChangeLog   |  5 +++++
 lisp/cus-edit.el | 29 +++++++++++++++++++++++------
 3 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/etc/TODO b/etc/TODO
index ccd00e5..cbb2394 100644
--- a/etc/TODO
+++ b/etc/TODO
@@ -419,12 +419,6 @@ rather than interactively.  This a trivial one-liner in easy-mode.el.
 
 ** Make byte-optimization warnings issue accurate line numbers.
 
-** A function to check for customizable options that have been
-  set but not saved, and ask the user whether to save them.
-  This could go in kill-emacs-query-functions, to remind people
-  to save their changes. If the user says yes, show them
-  in a Custom buffer using customize-customized.
-
 ** Record the sxhash of the default value for customized variables
   and notify the user (maybe by adding a menu item or toolbar button,
   as the detection can occur during autoload time) when the default
diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index bf139d6..9e4a7a7 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,8 @@
+2014-12-09  Cameron Desautels  <camdez@gmail.com>
+
+	* cus-edit.el (custom-prompt-customize-unsaved-options): Add a
+	mechanism for prompting user about unsaved customizations.
+
 2014-12-09  Eric S. Raymond  <esr@snark.thyrsus.com>
 
 	* vc/vc-src.el (vc-src-do-comand): Prepend -- to file argument
diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
index c8e9b90..a6da50e 100644
--- a/lisp/cus-edit.el
+++ b/lisp/cus-edit.el
@@ -1356,12 +1356,10 @@ suggest to customize that face, if it's customizable."
                                      (or (face-at-point t t) "all faces") t)))
   (customize-face face t))
 
-(defalias 'customize-customized 'customize-unsaved)
-
-;;;###autoload
-(defun customize-unsaved ()
-  "Customize all options and faces set in this session but not saved."
-  (interactive)
+(defun custom-unsaved-options ()
+  "List of options and faces set in this session but not saved.
+Each entry is of the form (SYMBOL TYPE), where TYPE is one of the
+symbols `custom-face' or `custom-variable'."
   (let ((found nil))
     (mapatoms (lambda (symbol)
 		(and (or (get symbol 'customized-face)
@@ -1372,6 +1370,15 @@ suggest to customize that face, if it's customizable."
 			 (get symbol 'customized-variable-comment))
 		     (boundp symbol)
 		     (push (list symbol 'custom-variable) found))))
+    found))
+
+(defalias 'customize-customized 'customize-unsaved)
+
+;;;###autoload
+(defun customize-unsaved ()
+  "Customize all options and faces set in this session but not saved."
+  (interactive)
+  (let ((found (custom-unsaved-options)))
     (if (not found)
 	(error "No user options are set but unsaved")
       (custom-buffer-create (custom-sort-items found t nil)
@@ -1477,6 +1484,16 @@ If TYPE is `groups', include only groups."
   (interactive (list (apropos-read-pattern "groups")))
   (customize-apropos regexp 'groups))
 
+;;;###autoload
+(defun custom-prompt-customize-unsaved-options ()
+  "Prompt user to customize any unsaved customization options.
+Return non-nil if user chooses to customize, for use in
+`kill-emacs-query-functions'."
+  (not (and (custom-unsaved-options)
+	    (yes-or-no-p "Some customized options have not been saved; Examine? ")
+	    (customize-unsaved)
+	    t)))
+
 ;;; Buffer.
 
 (defcustom custom-buffer-style 'links
-- 
2.2.0

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Drew Adams]

Why is this in etc/TODO?

This already exists, no?  I've been using this for years:

(add-hook 'kill-emacs-query-functions
          (lambda ()
            (condition-case nil
                (customize-unsaved)
              (error t))))


> Implements the following, as requested in `etc/TODO`:
>
> ** A function to check for customizable options that have been
>    set but not saved, and ask the user whether to save them.
>    This could go in kill-emacs-query-functions, to remind people
>    to save their changes. If the user says yes, show them
>    in a Custom buffer using customize-customized.

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Cameron Desautels]

> On 2014-12-09, at 9:54 AM, Drew Adams <drew.adams@oracle.com> wrote:
> 
> Why is this in etc/TODO?

If you're asking me in particular, I don't know. I just found it there
and thought I'd help out.

> This already exists, no?  I've been using this for years:
> 
> (add-hook 'kill-emacs-query-functions
>          (lambda ()
>            (condition-case nil
>                (customize-unsaved)
>              (error t))))

A named function is probably more suitable for an end user than an
arbitrary lambda, no?  Plus using error handling for control flow is
generally not considered a best practice, especially when it's as
broad in scope as `(condition-case nil ...)`.

-- 
Cameron Desautels <camdez@gmail.com>

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Drew Adams]

> > Why is this in etc/TODO?
> 
> If you're asking me in particular, I don't know. I just found it
> there and thought I'd help out.

Thanks for helping out!  The question is for Emacs Dev in general,
i.e., for this bug thread.

> > This already exists, no?  I've been using this for years:
> >
> > (add-hook 'kill-emacs-query-functions
> >          (lambda ()
> >            (condition-case nil
> >                (customize-unsaved)
> >              (error t))))
> 
> A named function is probably more suitable for an end user than an
> arbitrary lambda, no?  Plus using error handling for control flow is
> generally not considered a best practice, especially when it's as
> broad in scope as `(condition-case nil ...)`.

That's what *I* use.  I'm not saying that everyone should use it.
My .emacs is used for multiple Emacs versions.  You might prefer
`ignore-errors', which does not exist in older versions.  Or you
might prefer not to ignore errors...

If you want a named function and no error handling, then, well,
try `customize-unsaved'.

My point was that `customized-unsaved' already exists.  It is
precisely a "mechanism to prompt about unsaved customizations".
Unless I'm missing something.  AFAICT, it is exactly what is
described in that TODO item:

   A function to check for customizable options that have been
   set but not saved, and ask the user whether to save them.
   This could go in kill-emacs-query-functions, to remind people
   to save their changes. If the user says yes, show them
   in a Custom buffer using customize-customized.

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Cameron Desautels]

Got it.  Thank you for the clarification, I think I see where our
thinking has diverged: `customize-unsaved' is the existing mechanism
to pop up a customize buffer displaying unsaved customization options.
I've put a thin layer around this which provides a yes / no prompt to
the user before (conditionally) invoking `customized-unsaved'. This is
in the general spirit of hooks that run when killing Emacs ("Modified
buffers exist", "Active processes exist", etc.).

> If you want a named function and no error handling, then, well, try
> `customize-unsaved'.

`customize-unsaved' is not suitable for use in
`kill-emacs-query-functions` because it signals an error if nothing
has been customized, meaning that it will block the user from quitting
Emacs if there are no unsaved customizations, and it will invoke the
customization mechanism there are any.  Ergo, they can never quit.
(Drew: I'm sure you're aware of this given the way you've wrapped the
call to `customize-unsaved', but I'm spelling it out for the benefit
of others.)

That said, the lambda you've added to `kill-emacs-query-functions'
doesn't function properly either (at least not on my machine).  It
returns `t' in the no-unsaved-customizations case (after catching the
error thrown my `customize-unsaved'), and it returns a (truthy)
string, courtesy of `customize-unsaved', in the
have-unsaved-custoizations case.  Truthy values returned by the
functions in `kill-emacs-query-functions' mean "continue with quitting
Emacs", ergo the user is never prompted about unsaved customizations.

Of course you can fix this easily by making sure to return nil in the
happy path, but you're working up to exactly what my patch does...

The one behavioral difference between the two is how we prompt: in the
patched version the user is prompted in the minibuffer: "Some
customized options have not been saved; Examine?", and shown a
customization buffer only if they say yes.

In yours, the customization buffer is automatically shown, without
explanation, and attempts to quit the editor will continue to fail
until the user finds either the `Revert...` or the `Apply and Save`
button.

I believe the patched version is a superior user experience.  Have I
managed to convince you? :)

-- 
Cameron Desautels <camdez@gmail.com>




> On 2014-12-09, at 10:24 AM, Drew Adams <drew.adams@oracle.com> wrote:
> 
>>> Why is this in etc/TODO?
>> 
>> If you're asking me in particular, I don't know. I just found it
>> there and thought I'd help out.
> 
> Thanks for helping out!  The question is for Emacs Dev in general,
> i.e., for this bug thread.
> 
>>> This already exists, no?  I've been using this for years:
>>> 
>>> (add-hook 'kill-emacs-query-functions
>>>         (lambda ()
>>>           (condition-case nil
>>>               (customize-unsaved)
>>>             (error t))))
>> 
>> A named function is probably more suitable for an end user than an
>> arbitrary lambda, no?  Plus using error handling for control flow is
>> generally not considered a best practice, especially when it's as
>> broad in scope as `(condition-case nil ...)`.
> 
> That's what *I* use.  I'm not saying that everyone should use it.
> My .emacs is used for multiple Emacs versions.  You might prefer
> `ignore-errors', which does not exist in older versions.  Or you
> might prefer not to ignore errors...
> 
> If you want a named function and no error handling, then, well,
> try `customize-unsaved'.
> 
> My point was that `customized-unsaved' already exists.  It is
> precisely a "mechanism to prompt about unsaved customizations".
> Unless I'm missing something.  AFAICT, it is exactly what is
> described in that TODO item:
> 
>   A function to check for customizable options that have been
>   set but not saved, and ask the user whether to save them.
>   This could go in kill-emacs-query-functions, to remind people
>   to save their changes. If the user says yes, show them
>   in a Custom buffer using customize-customized.

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Drew Adams]

> Got it.  Thank you for the clarification, I think I see where our
> thinking has diverged: `customize-unsaved' is the existing mechanism
> to pop up a customize buffer displaying unsaved customization
> options. I've put a thin layer around this which provides a yes / no
> prompt to the user before (conditionally) invoking `customized-unsaved'.
> This is in the general spirit of hooks that run when killing Emacs
> ("Modified buffers exist", "Active processes exist", etc.).
> 
> > If you want a named function and no error handling, then, well,
> > try `customize-unsaved'.
> 
> `customize-unsaved' is not suitable for use in
> `kill-emacs-query-functions` because it signals an error if nothing
> has been customized, meaning that it will block the user from
> quitting Emacs if there are no unsaved customizations, and it will
> invoke the customization mechanism there are any.  Ergo, they can
> never quit. (Drew: I'm sure you're aware of this given the way you've
> wrapped the call to `customize-unsaved', but I'm spelling it out
> for the benefit of others.)
> 
> That said, the lambda you've added to `kill-emacs-query-functions'
> doesn't function properly either (at least not on my machine).  It
> returns `t' in the no-unsaved-customizations case (after catching
> the error thrown my `customize-unsaved'), and it returns a (truthy)
> string, courtesy of `customize-unsaved', in the
> have-unsaved-custoizations case.  Truthy values returned by the
> functions in `kill-emacs-query-functions' mean "continue with
> quitting Emacs", ergo the user is never prompted about unsaved
> customizations.
> 
> Of course you can fix this easily by making sure to return nil in
> the happy path, but you're working up to exactly what my patch does...
> 
> The one behavioral difference between the two is how we prompt: in
> the patched version the user is prompted in the minibuffer: "Some
> customized options have not been saved; Examine?", and shown a
> customization buffer only if they say yes.
> 
> In yours, the customization buffer is automatically shown, without
> explanation, and attempts to quit the editor will continue to fail
> until the user finds either the `Revert...` or the `Apply and Save`
> button.
> 
> I believe the patched version is a superior user experience.  Have I
> managed to convince you? :)

OK.  In fact, I use `cus-edit+.el', which redefines `customize-unsaved'
so that it DTRT.  I offered this to Emacs Dev long ago, but no interest.
Perhaps you will have better luck. ;-)

FWIW, These are the changes I made to `customize-unsaved':

;; 1. By default, ignores preferences in `customize-customized-ignore'.
;; 2. Added prefix arg to override `customize-customized-ignore'.
;; 3. When not interactive and there are changes, ask for confirmation.
;; 4. Always returns `t', so it can be used as a
;;    `kill-emacs-query-functions' hook.
;; 5. Wrap in `condition-case' and reissue error.

The code is here, in case you are interested:
http://www.emacswiki.org/emacs-en/download/cus-edit%2b.el

And here is some info about it:
http://www.emacswiki.org/CustomizingAndSaving#CustomizePlus

HTH.

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Cameron Desautels]

> FWIW, These are the changes I made to `customize-unsaved':

> ;; 1. By default, ignores preferences in `customize-customized-ignore'.
> ;; 2. Added prefix arg to override `customize-customized-ignore'.
> ;; 3. When not interactive and there are changes, ask for confirmation.
> ;; 4. Always returns `t', so it can be used as a
> ;;    `kill-emacs-query-functions' hook.
> ;; 5. Wrap in `condition-case' and reissue error.

Thank you for sharing that!  I looked through it to see if I'm missing
anything important.  Your code is much more ambitious than the humble
patch I'm offering.  I definitely see the rationale behind your work
on `cus-edit+.el' but I think the important parts of it are orthogonal
to what I've done here.

WRT the five items above, 1 & 2 can be disregarded here because
`customize-customized-ignore' only exists in your library (and is only
necessary because of the elimination of the "changed outside of
Customize" state).

3-5 I cover differently--a new function rather than changing the
behavior of `customize-unsaved'--and this way has the benefit of being
minimally invasive (i.e. shouldn't break anyone else's code).

TLDR I still think it makes sense to merge the patch.

-- 
Cameron Desautels <camdez@gmail.com>

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Drew Adams]

> 3-5 I cover differently--a new function rather than changing the
> behavior of `customize-unsaved'--and this way has the benefit of
> being minimally invasive (i.e. shouldn't break anyone else's code).

OK by me.  (I didn't look at the patch, but the idea sounds OK.)

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Ted Zlatanov]

On Tue, 9 Dec 2014 09:46:22 -0600 Cameron Desautels <camdez@gmail.com> wrote: 

CD> Implements the following, as requested in `etc/TODO`:
CD> ** A function to check for customizable options that have been
CD>    set but not saved, and ask the user whether to save them.
CD>    This could go in kill-emacs-query-functions, to remind people
CD>    to save their changes. If the user says yes, show them
CD>    in a Custom buffer using customize-customized.

CD> My copyright assignment info should be on file.

I like it!

Could you add a NEWS entry and maybe some docs in the manual?  I think
it's very helpful for beginners.  The code looks OK to me.

Ted

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Cameron Desautels]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

> Could you add a NEWS entry and maybe some docs in the manual?  I think
> it's very helpful for beginners.  The code looks OK to me.

Absolutely!  I've attached an updated version of the patch with the
requested additions.

What about turning something like this on by default?  Any strong
opinions?  Having it available to add to the hook is a step in the
right direction, but the users most likely to be helped by it are (I
assume) less likely to be editing their initialization file by hand.

If it does make sense to turn it on by default then I suspect the
implementation would be rather different from a call to `add-hook' (it
seems a bit odd to have a user call `remove-hook' to turn off the
behavior), so perhaps an addition to `save-buffers-kill-emacs' and a
variable to toggle the feature would be in order?
--
Cameron Desautels <camdez@gmail.com>

[-- Attachment #2: 0001-Add-mechanism-to-prompt-about-unsaved-customizations.patch --]
[-- Type: application/octet-stream, Size: 5062 bytes --]

From 24f25fa806d663d837787cc301386b887d2e0b19 Mon Sep 17 00:00:00 2001
From: Cameron Desautels <camdez@gmail.com>
Date: Tue, 9 Dec 2014 00:28:44 -0600
Subject: [PATCH] Add mechanism to prompt about unsaved customizations

- Requested in `etc/TODO'
- Suitable for use in `kill-emacs-query-functions'.
---
 doc/emacs/custom.texi | 10 ++++++++++
 etc/NEWS              |  3 +++
 etc/TODO              |  6 ------
 lisp/ChangeLog        |  5 +++++
 lisp/cus-edit.el      | 29 +++++++++++++++++++++++------
 5 files changed, 41 insertions(+), 12 deletions(-)

diff --git a/doc/emacs/custom.texi b/doc/emacs/custom.texi
index 0d0013f..6c392cb 100644
--- a/doc/emacs/custom.texi
+++ b/doc/emacs/custom.texi
@@ -405,6 +405,16 @@ customizations in your initialization file.  This is because saving
 customizations from such a session would wipe out all the other
 customizations you might have on your initialization file.
 
+  Please note that any customizations you have not chosen to save for
+future sessions will be lost when you terminate Emacs.  If you'd like
+to be prompted about unsaved customizations at termination time, add
+the following to your initialization file:
+
+@example
+(add-hook 'kill-emacs-query-functions
+          'custom-prompt-customize-unsaved-options)
+@end example
+
 @node Face Customization
 @subsection Customizing Faces
 @cindex customizing faces
diff --git a/etc/NEWS b/etc/NEWS
index 58a5836..a583af2 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -49,6 +49,9 @@ Use './configure PKG_CONFIG=/full/name/of/pkg-config' if you need to.
 \f
 * Changes in Emacs 25.1
 
+** New function `custom-prompt-customize-unsaved-options' checks for
+unsaved customizations and prompts user to customize (if found).
+
 +++
 ** Network security (TLS/SSL certificate validity and the like) is
 added via the new Network Security Manager (NSM) and controlled via
diff --git a/etc/TODO b/etc/TODO
index ccd00e5..cbb2394 100644
--- a/etc/TODO
+++ b/etc/TODO
@@ -419,12 +419,6 @@ rather than interactively.  This a trivial one-liner in easy-mode.el.
 
 ** Make byte-optimization warnings issue accurate line numbers.
 
-** A function to check for customizable options that have been
-  set but not saved, and ask the user whether to save them.
-  This could go in kill-emacs-query-functions, to remind people
-  to save their changes. If the user says yes, show them
-  in a Custom buffer using customize-customized.
-
 ** Record the sxhash of the default value for customized variables
   and notify the user (maybe by adding a menu item or toolbar button,
   as the detection can occur during autoload time) when the default
diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 452f4c3..0bd5a03 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,8 @@
+2014-12-11  Cameron Desautels  <camdez@gmail.com>
+
+	* cus-edit.el (custom-prompt-customize-unsaved-options): Add a
+	mechanism for prompting user about unsaved customizations.
+
 2014-12-11  Michael Albinus  <michael.albinus@gmx.de>
 
 	* vc/vc-hg.el (vc-hg-state): Make FILE absolute.  Handle the case
diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
index c8e9b90..a6da50e 100644
--- a/lisp/cus-edit.el
+++ b/lisp/cus-edit.el
@@ -1356,12 +1356,10 @@ suggest to customize that face, if it's customizable."
                                      (or (face-at-point t t) "all faces") t)))
   (customize-face face t))
 
-(defalias 'customize-customized 'customize-unsaved)
-
-;;;###autoload
-(defun customize-unsaved ()
-  "Customize all options and faces set in this session but not saved."
-  (interactive)
+(defun custom-unsaved-options ()
+  "List of options and faces set in this session but not saved.
+Each entry is of the form (SYMBOL TYPE), where TYPE is one of the
+symbols `custom-face' or `custom-variable'."
   (let ((found nil))
     (mapatoms (lambda (symbol)
 		(and (or (get symbol 'customized-face)
@@ -1372,6 +1370,15 @@ suggest to customize that face, if it's customizable."
 			 (get symbol 'customized-variable-comment))
 		     (boundp symbol)
 		     (push (list symbol 'custom-variable) found))))
+    found))
+
+(defalias 'customize-customized 'customize-unsaved)
+
+;;;###autoload
+(defun customize-unsaved ()
+  "Customize all options and faces set in this session but not saved."
+  (interactive)
+  (let ((found (custom-unsaved-options)))
     (if (not found)
 	(error "No user options are set but unsaved")
       (custom-buffer-create (custom-sort-items found t nil)
@@ -1477,6 +1484,16 @@ If TYPE is `groups', include only groups."
   (interactive (list (apropos-read-pattern "groups")))
   (customize-apropos regexp 'groups))
 
+;;;###autoload
+(defun custom-prompt-customize-unsaved-options ()
+  "Prompt user to customize any unsaved customization options.
+Return non-nil if user chooses to customize, for use in
+`kill-emacs-query-functions'."
+  (not (and (custom-unsaved-options)
+	    (yes-or-no-p "Some customized options have not been saved; Examine? ")
+	    (customize-unsaved)
+	    t)))
+
 ;;; Buffer.
 
 (defcustom custom-buffer-style 'links
-- 
2.2.0

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Stefan Monnier]

> What about turning something like this on by default?

I'm not necessarily opposed to it, but I wonder if it's
sufficiently unintrusive.

E.g. if you just want to try out a minor mode like global-auto-revert-mode,
IIUC this will set the var and mark it as "set but unsaved", so when you
exit, Emacs will prompt you to save this setting.

Maybe it's actually the right thing to do, but I wonder if it will turn
out to be more annoying than useful.  And I don't see a good solution for it.


        Stefan

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Cameron Desautels]

> I'm not necessarily opposed to it, but I wonder if it's
> sufficiently unintrusive.

Well, on quick sessions in-and-out of Emacs (say, on git commits), users
will never be prompted because there won't be any customizations.  But I
suspect that if someone took the time to edit their preferences, odds
are good they want them saved.  Experiments to try something like
`global-auto-revert-mode' seem like the minority of cases (plus "no" isn't
*that* long of a word in the event that you are prompted), and more
serious Emacs users (1) don't even close Emacs that often, (2) probably
have most of their configuration done through handwritten Elisp, and (3)
can easily disable the prompt.  Hell, we could even make the "prompt for
unsaved customizations" option customizable.

I don't have an exceedingly strong opinion but FWIW I sat down to hack
this out after seeing a friend and Emacs newbie spend quite a while
customizing faces for visibility and then lose it all at quit time.
Then I found the same request in the TODO file and it seemed worth
doing.  Obviously that's highly anecdotal, but I can imagine it being a
common problem.
--
Cameron Desautels <camdez@gmail.com>


On Thu, Dec 11, 2014 at 7:40 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> What about turning something like this on by default?
>
> I'm not necessarily opposed to it, but I wonder if it's
> sufficiently unintrusive.
>
> E.g. if you just want to try out a minor mode like global-auto-revert-mode,
> IIUC this will set the var and mark it as "set but unsaved", so when you
> exit, Emacs will prompt you to save this setting.
>
> Maybe it's actually the right thing to do, but I wonder if it will turn
> out to be more annoying than useful.  And I don't see a good solution for it.
>
>
>         Stefan

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Stefan Monnier]

> I don't have an exceedingly strong opinion but FWIW I sat down to hack
> this out after seeing a friend and Emacs newbie spend quite a while
> customizing faces for visibility and then lose it all at quit time.
> Then I found the same request in the TODO file and it seemed worth
> doing.  Obviously that's highly anecdotal, but I can imagine it being a
> common problem.

Oh yes, I'm quite aware of this problem, which is why I think this
feature is very nice and that's also why I'm saying that I'm not
necessarily opposed to enabling it by default.

But I'd like to some opinion from people who've actually tried it.

Many Emacs users can have very strong reactions to very small changes in
the default behavior.  The potential benefit justifies a bit of
potential annoyance, and I think I can evaluate the potential benefit,
but I don't think I can evaluate the potential annoyance yet.


        Stefan

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Cameron Desautels]

On Thu, Dec 11, 2014 at 8:36 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> Oh yes, I'm quite aware of this problem, which is why I think this
> feature is very nice and that's also why I'm saying that I'm not
> necessarily opposed to enabling it by default.
>
> But I'd like to some opinion from people who've actually tried it.
>
> Many Emacs users can have very strong reactions to very small changes in
> the default behavior.  The potential benefit justifies a bit of
> potential annoyance, and I think I can evaluate the potential benefit,
> but I don't think I can evaluate the potential annoyance yet.

Got it.  Seems like a wise approach.  Let me know how I can help.

--
Cameron Desautels <camdez@gmail.com>

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Ted Zlatanov]

On Thu, 11 Dec 2014 20:39:39 -0600 Cameron Desautels <camdez@gmail.com> wrote: 

CD> On Thu, Dec 11, 2014 at 8:36 PM, Stefan Monnier
CD> <monnier@iro.umontreal.ca> wrote:
>> Oh yes, I'm quite aware of this problem, which is why I think this
>> feature is very nice and that's also why I'm saying that I'm not
>> necessarily opposed to enabling it by default.
>> 
>> But I'd like to some opinion from people who've actually tried it.
>> 
>> Many Emacs users can have very strong reactions to very small changes in
>> the default behavior.  The potential benefit justifies a bit of
>> potential annoyance, and I think I can evaluate the potential benefit,
>> but I don't think I can evaluate the potential annoyance yet.

CD> Got it.  Seems like a wise approach.  Let me know how I can help.

To make it easier for people to try it, and to format the patch a little
better, I've pushed it on top of the current master branch in the branch
scratch/bug19328/custom-prompt-customize-unsaved-options from where it
can be tried or cherry-picked.

Ted

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Stefan Monnier]

> To make it easier for people to try it, and to format the patch a little
> better, I've pushed it on top of the current master branch in the branch
> scratch/bug19328/custom-prompt-customize-unsaved-options from where it
> can be tried or cherry-picked.

No!  Please install it into master.
This part is not under debate.  The only debate is whether to enable it
by default.


        Stefan

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Ted Zlatanov]

On Sat, 13 Dec 2014 00:55:08 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> To make it easier for people to try it, and to format the patch a little
>> better, I've pushed it on top of the current master branch in the branch
>> scratch/bug19328/custom-prompt-customize-unsaved-options from where it
>> can be tried or cherry-picked.

SM> No!  Please install it into master.
SM> This part is not under debate.  The only debate is whether to enable it
SM> by default.

Could you review the commit first?  I wasn't sure about the commit
message, since it's one commit for several scattered ChangeLogs (and
those ChangeLog deltas are not in the commit message details).  I think
it's reasonable but didn't want to presume.

Ted

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Cameron Desautels]

Ted: thanks for adding the additional ChangeLog entries--I didn't
realize just how many ChangeLog files there are.  FWIW the patch looks
good to me.
--
Cameron Desautels <camdez@gmail.com>


On Sat, Dec 13, 2014 at 7:06 AM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Sat, 13 Dec 2014 00:55:08 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>>> To make it easier for people to try it, and to format the patch a little
>>> better, I've pushed it on top of the current master branch in the branch
>>> scratch/bug19328/custom-prompt-customize-unsaved-options from where it
>>> can be tried or cherry-picked.
>
> SM> No!  Please install it into master.
> SM> This part is not under debate.  The only debate is whether to enable it
> SM> by default.
>
> Could you review the commit first?  I wasn't sure about the commit
> message, since it's one commit for several scattered ChangeLogs (and
> those ChangeLog deltas are not in the commit message details).  I think
> it's reasonable but didn't want to presume.
>
> Ted

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Ted Zlatanov]

On Sat, 13 Dec 2014 08:06:32 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sat, 13 Dec 2014 00:55:08 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>>> To make it easier for people to try it, and to format the patch a little
>>> better, I've pushed it on top of the current master branch in the branch
>>> scratch/bug19328/custom-prompt-customize-unsaved-options from where it
>>> can be tried or cherry-picked.

SM> No!  Please install it into master.
SM> This part is not under debate.  The only debate is whether to enable it
SM> by default.

TZ> Could you review the commit first?  I wasn't sure about the commit
TZ> message, since it's one commit for several scattered ChangeLogs (and
TZ> those ChangeLog deltas are not in the commit message details).  I think
TZ> it's reasonable but didn't want to presume.

...I see for example the commit 49daed60510a073062b41fa39fd7c010cb0a315e
from Glenn has a nice summary of all the changes in subdirectories
gathered from various ChangeLogs, but `C-c C-a' in the commit window
doesn't bring in anything near that summary. Is there a way to
auto-generate it or do I have to assemble it by hand?

I created the top-level commit message by hand for now, in
scratch/bug19328/custom-prompt-customize-unsaved-options-rc2 and then
merged it, so the discussion about enabling this feature by default can
continue (I'm not marking the bug "done")...

Ted

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Stefan Monnier]

> ...I see for example the commit 49daed60510a073062b41fa39fd7c010cb0a315e
> from Glenn has a nice summary of all the changes in subdirectories
> gathered from various ChangeLogs, but `C-c C-a' in the commit window
> doesn't bring in anything near that summary. Is there a way to
> auto-generate it or do I have to assemble it by hand?

Yes: from the *vc-dir* buffer, you need to explicitly select every file
you'll commit (instead of just saying "commit everything in this
directory").  Then C-c C-a will work.  It's stupid but it's the way to
code works.  Patches welcome.


        Stefan

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Ted Zlatanov]

On Sun, 14 Dec 2014 09:02:48 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> ...I see for example the commit 49daed60510a073062b41fa39fd7c010cb0a315e
>> from Glenn has a nice summary of all the changes in subdirectories
>> gathered from various ChangeLogs, but `C-c C-a' in the commit window
>> doesn't bring in anything near that summary. Is there a way to
>> auto-generate it or do I have to assemble it by hand?

SM> Yes: from the *vc-dir* buffer, you need to explicitly select every file
SM> you'll commit (instead of just saying "commit everything in this
SM> directory").  Then C-c C-a will work.  It's stupid but it's the way to
SM> code works.  Patches welcome.

Oh, huh, yeah that's kind of strange.  I'd expect it to work when
nothing is selected.  I'll try to hack it, some time this century :)

Ted

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> To make it easier for people to try it, and to format the patch a little
>> better, I've pushed it on top of the current master branch in the branch
>> scratch/bug19328/custom-prompt-customize-unsaved-options from where it
>> can be tried or cherry-picked.
>
> No!  Please install it into master.
> This part is not under debate.  The only debate is whether to enable it
> by default.

It looks like the patch was committed, and presumably any debate that
was going to happen has happened, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19328: [PATCH] Add mechanism to prompt about unsaved customizations

[Drew Adams]

> > What about turning something like this on by default?
> 
> I'm not necessarily opposed to it, but I wonder if it's
> sufficiently unintrusive.
> 
> E.g. if you just want to try out a minor mode like global-auto-
> revert-mode, IIUC this will set the var and mark it as
> "set but unsaved", so when you exit, Emacs will prompt you to
> save this setting.
> 
> Maybe it's actually the right thing to do, but I wonder if it will
> turn out to be more annoying than useful.  And I don't see a good
> solution for it.

FWIW, in the version of this feature that I use:

1. You are not asked to save the changes.  You are asked whether
   you want to see the changed options (in Customize).  If/when
   you see them, you can quit or save any or all of them first.

2. There are some ways to deal with changes that you don't care
   about.  From the `cus-edit+.el' file header:

;;  Dealing with Spurious Changes, 1: Save
;;  --------------------------------------
;;
;;  Even if you don't change any preferences yourself, when
;;  you quit Emacs the first time you are informed that
;;  there are lots of changed preferences, and you are given
;;  a chance to save those changes.  What are those changes?
;;  They represent all of the user preferences that Emacs
;;  and various Emacs libraries have changed behind
;;  Customize's back - even before you did anything.
;;
;;  You'll see user options like `baud-rate' that are set in
;;  Emacs C code without informing Customize to mark their
;;  settings as `standard' (= installed).  There shouldn't
;;  be any such apparent "changes", since this is part of
;;  standard Emacs, but that's the way it is, for now.
;;  Customize is still fairly new, and lots of Emacs
;;  libraries still define and change user preferences
;;  without going through Customize and, in effect, telling
;;  it not to consider such preference changes as changes.
;;
;;  If you choose to save these preference changes, you will
;;  never again be bothered by being informed that they have
;;  changed (unless you change them).  So, that's one
;;  solution to this bother, which makes it a one-time only
;;  nuisance: just say "save all".
;;
;;  Dealing with Spurious Changes, 2: Ignore
;;  ----------------------------------------
;;
;;  Another solution is also possible.  Some user
;;  preferences, like `case-fold-search' and
;;  `debug-on-error' are really the kind of thing that you
;;  change often and temporarily - you don't really care
;;  about saving their changes, and you certainly don't want
;;  to be asked whether or not you want to save them each
;;  time you quit Emacs.
;;
;;  To deal with that, a list of ignored preferences,
;;  `customize-customized-ignore', is defined here.  Its
;;  preferences (symbols) are not used by
;;  `customize-unsaved' at all (you can override that
;;  interactively with a prefix arg).  So, the other way to
;;  deal with the legacy Emacs preferences, besides just
;;  saving them in your custom file, is to add them to
;;  `customize-customized-ignore' so `customize-unsaved'
;;  will ignore them.
;;
;;  To make it easy for you to add preferences to this
;;  ignore list, `Ignore Unsaved Changes' menu items and
;;  buttons have been added.  You can choose to ignore
;;  specific preferences or all preferences in a Customize
;;  buffer - in particular, all preferences in the Customize
;;  buffer from `customize-unsaved' (all changed
;;  preferences).
;;
;;  Dealing with Spurious Changes, 3: Consider Unchanged
;;  ----------------------------------------------------
;;
;;  There is also a third way to treat preference changes
;;  that you are not responsible for, as an alternative to
;;  saving them to your custom file or having Customize
;;  always ignore them: tell Customize to consider the
;;  current changes as unchanged.  This essentially treats
;;  them as having been saved, but without saving them.  You
;;  can do this using the `Consider Unchanged' menu items
;;  and buttons added here.
;;
;;  For instance, after starting Emacs, you can examine the
;;  current preference changes (using `customize-unsaved')
;;  from Emacs itself and loaded libraries, and choose
;;  `Consider Unchanged' to let Customize know that the
;;  current values are to be treated as if they were saved,
;;  but without actually saving them to your custom file.
;;  That way, your custom file is not polluted with things
;;  that you are not really concerned with, yet you are not
;;  bothered by seeing such fictitious changes show up each
;;  time you check for changes.
;;
;;  However, unlike ignoring changes to certain preferences,
;;  and really saving current preference values, `Consider
;;  Unchanged' is not a persistent change.  You can use it
;;  at any time to "reset" the change counter for given
;;  preferences, so that the current change is considered
;;  the new base value (as if it were saved), and any
;;  further changes you make to them will show up as
;;  changes, using `customize-unsaved'.

And note that in my version it is `customize-unsaved'
itself that is modified, so the advantageous behavior is
available also when that command is used interactively.