GNU bug report logs - #41473
Not saving all user options

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41473 in the body.
You can then email your comments to 41473 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Philip K." <philip <at> warpmail.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Not saving all user options
Date: Sat, 23 May 2020 10:04:19 +0200

[Message part 1 (text/plain, inline)]

Hi,

I was rewriting parts of my configuration recently, and one important
change was to use `customize-set-variable' more extensivly (via a
setq-like macro). What annoys me is that even though I specify all the
variables in my init.el, they eventually get regenerated in my
`custom-file'. The standard solutions seems to have been setting
`custom-file' to /dev/null, but since I like to use the ECI for
temporary changes.

What I would be interested in, would be a way to tell customize not to
write out a user-option, to keep configurations cleaner. I tried this in
the patch bellow, by checking of the comment starts with four or more
spaces, but it could just as well be any other predicate such as a
string starting with a zero-width whitespace, the string "NONSAVE" or a
property in the symbol plist. The important thing would be that macros
such as my setq-like macro, or use-package could keep the entire
configuration cleaner, without having to give up on a `custom-file'
entierly -- ideally a pure user wouldn't even notice.

Is there any argument against something like this in principle, or is
there already such a mechanism I overlooked?

-- 
	Philip K.

[0001-Inhibit-saving-user-options-when-comments-start-with.patch (text/x-diff, inline)]

From 06d4030245e037b2e7e88180cda542c5ebd22ebb Mon Sep 17 00:00:00 2001
From: Philip K <philip <at> warpmail.net>
Date: Sat, 23 May 2020 09:47:49 +0200
Subject: [PATCH] Inhibit saving user options when comments start with =<4
 spaces

---
 lisp/cus-edit.el | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
index 1ec2708550..510b1b3711 100644
--- a/lisp/cus-edit.el
+++ b/lisp/cus-edit.el
@@ -4594,17 +4594,21 @@ custom-save-variables
   (save-excursion
     (custom-save-delete 'custom-set-variables)
     (let ((standard-output (current-buffer))
-	  (saved-list (make-list 1 0))
-	  sort-fold-case)
+	  saved-list sort-fold-case)
       ;; First create a sorted list of saved variables.
       (mapatoms
        (lambda (symbol)
-	 (if (and (get symbol 'saved-value)
-		  ;; ignore theme values
-		  (or (null (get symbol 'theme-value))
-		      (eq 'user (caar (get symbol 'theme-value)))))
-	     (nconc saved-list (list symbol)))))
-      (setq saved-list (sort (cdr saved-list) 'string<))
+	 (when (and (get symbol 'saved-value)
+                    ;; don't save comments with four or more preceding
+                    ;; space charachters
+                    (not (string-match-p
+                          "^[[:space:]]{4,}"
+                          (get symbol 'saved-variable-comment)))
+		    ;; ignore theme values
+		    (or (null (get symbol 'theme-value))
+		        (eq 'user (caar (get symbol 'theme-value)))))
+	   (push symbol saved-list))))
+      (setq saved-list (sort saved-list 'string<))
       (unless (bolp)
 	(princ "\n"))
       (princ "(custom-set-variables
-- 
2.20.1

Message #8 received at 41473 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: "Philip K." <philip <at> warpmail.net>
Cc: 41473 <at> debbugs.gnu.org
Subject: Re: bug#41473: Not saving all user options
Date: Fri, 29 May 2020 10:06:04 -0400

severity 41473 wishlist
quit

"Philip K." <philip <at> warpmail.net> writes:

> the patch bellow, by checking of the comment starts with four or more
> spaces, but it could just as well be any other predicate such as a
> string starting with a zero-width whitespace, the string "NONSAVE" or a
> property in the symbol plist.

> Is there any argument against something like this in principle, or is
> there already such a mechanism I overlooked?

I don't see any.  Regarding your suggestions in particular, I think the
plist method would be the cleanest.  Four spaces strikes me as overly
cryptic.

Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Philip K." <philip <at> warpmail.net>
To: npostavs <at> gmail.com
Cc: bug-gnu-emacs <at> gnu.org, 41473 <at> debbugs.gnu.org
Subject: bug#41473: Not saving all user options 
Date: Fri, 26 Jun 2020 21:59:51 +0200

[Message part 1 (text/plain, inline)]

> I don't see any.  Regarding your suggestions in particular, I think
> the plist method would be the cleanest.  Four spaces strikes me as
> overly cryptic.

The patch below should implement that behaviour. The property
"custom-inhibit-save" doesn't seem to be used anywhere else, so that
should be OK.

-- 
	Philip K.

[0001-Allow-inhibiting-a-user-option-from-being-saved.patch (text/x-diff, inline)]

From 07097f7bb79e5014ceafcb02563c173938e079bc Mon Sep 17 00:00:00 2001
From: Philip K <philip <at> warpmail.net>
Date: Fri, 26 Jun 2020 21:54:36 +0200
Subject: [PATCH] Allow inhibiting a user option from being saved

---
 lisp/cus-edit.el | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el
index 1ec2708550..6bd11908ce 100644
--- a/lisp/cus-edit.el
+++ b/lisp/cus-edit.el
@@ -4594,17 +4594,19 @@ custom-save-variables
   (save-excursion
     (custom-save-delete 'custom-set-variables)
     (let ((standard-output (current-buffer))
-	  (saved-list (make-list 1 0))
-	  sort-fold-case)
+	  saved-list sort-fold-case)
       ;; First create a sorted list of saved variables.
       (mapatoms
        (lambda (symbol)
-	 (if (and (get symbol 'saved-value)
-		  ;; ignore theme values
-		  (or (null (get symbol 'theme-value))
-		      (eq 'user (caar (get symbol 'theme-value)))))
-	     (nconc saved-list (list symbol)))))
-      (setq saved-list (sort (cdr saved-list) 'string<))
+	 (when (and (get symbol 'saved-value)
+		    ;; ignore theme values
+		    (or (null (get symbol 'theme-value))
+		        (eq 'user (caar (get symbol 'theme-value))))
+                    ;; don't save comments if the symbol as a non-nil
+                    ;; value for it's `custom-inhibit-save' property
+                    (not (get symbol 'custom-inhibit-save)))
+	   (push symbol saved-list))))
+      (setq saved-list (sort saved-list 'string<))
       (unless (bolp)
 	(princ "\n"))
       (princ "(custom-set-variables
-- 
2.20.1

Message #19 received at 41473 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Philip K." <philip <at> warpmail.net>
Cc: npostavs <at> gmail.com, 41473 <at> debbugs.gnu.org
Subject: Re: bug#41473: Not saving all user options
Date: Sat, 27 Jun 2020 10:17:02 +0300

> From: "Philip K." <philip <at> warpmail.net>
> Date: Fri, 26 Jun 2020 21:59:51 +0200
> Cc: 41473 <at> debbugs.gnu.org
> 
> > I don't see any.  Regarding your suggestions in particular, I think
> > the plist method would be the cleanest.  Four spaces strikes me as
> > overly cryptic.
> 
> The patch below should implement that behaviour. The property
> "custom-inhibit-save" doesn't seem to be used anywhere else, so that
> should be OK.

Can we please go a step back, and discuss why such a feature would be
needed?  Your original report says you are annoyed, but provides no
rationale and no real problems with the current behavior.  Could you
please elaborate on the nature of your annoyance?

Thanks.

Message #22 received at 41473 <at> debbugs.gnu.org (full text, mbox):

From: "Philip K." <philip <at> warpmail.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: npostavs <at> gmail.com, 41473 <at> debbugs.gnu.org
Subject: Re: bug#41473: Not saving all user options
Date: Sat, 27 Jun 2020 10:21:59 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: "Philip K." <philip <at> warpmail.net>
>> Date: Fri, 26 Jun 2020 21:59:51 +0200
>> Cc: 41473 <at> debbugs.gnu.org
>> 
>> > I don't see any.  Regarding your suggestions in particular, I think
>> > the plist method would be the cleanest.  Four spaces strikes me as
>> > overly cryptic.
>> 
>> The patch below should implement that behaviour. The property
>> "custom-inhibit-save" doesn't seem to be used anywhere else, so that
>> should be OK.
>
> Can we please go a step back, and discuss why such a feature would be
> needed?  Your original report says you are annoyed, but provides no
> rationale and no real problems with the current behavior.  Could you
> please elaborate on the nature of your annoyance?
>
> Thanks.

Sorry about that. 

The motivation I have and have seen a lot of other people share is that
when using macros such as use-package or as in my case a macro that
wraps customize-set-variable, my configuration is duplicated. If I
modify a variable in my init.el, but a saved value still persists in the
custom-set-variables form, then these changes won't take effect, and
it's not immediately obvious why. (This of course depends on when the
customisations are loaded).

Then there's also the minor problem that using a configuration macro for
customize usually means that the configuration is evaluated twice, which
doesn't seem necessary.

By adding a way to inhibit an user option from being saved, such as the
non-nil property values I suggested before, a configuration macro can
indicate that this macro doesn't have to be separately saved, because
it has already been taken care of.

-- 
	Philip K.

Message #25 received at 41473 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Philip K." <philip <at> warpmail.net>
Cc: npostavs <at> gmail.com, 41473 <at> debbugs.gnu.org
Subject: Re: bug#41473: Not saving all user options
Date: Sat, 27 Jun 2020 11:48:08 +0300

> From: "Philip K." <philip <at> warpmail.net>
> Cc: npostavs <at> gmail.com, 41473 <at> debbugs.gnu.org
> Date: Sat, 27 Jun 2020 10:21:59 +0200
> 
> > Can we please go a step back, and discuss why such a feature would be
> > needed?  Your original report says you are annoyed, but provides no
> > rationale and no real problems with the current behavior.  Could you
> > please elaborate on the nature of your annoyance?
> >
> > Thanks.
> 
> Sorry about that. 
> 
> The motivation I have and have seen a lot of other people share is that
> when using macros such as use-package or as in my case a macro that
> wraps customize-set-variable, my configuration is duplicated. If I
> modify a variable in my init.el, but a saved value still persists in the
> custom-set-variables form, then these changes won't take effect, and
> it's not immediately obvious why. (This of course depends on when the
> customisations are loaded).

Isn't this a problem to be solved by use-package or any other feature
which works similarly?  Why do we have to have something in core for
such a solution?

If the issue is to disable saving a customized variable, then we
already have the 'saved-value' property (and possibly other properties
that have special meaning for custom.el) which can be manipulated to
avoid the saving.

And if the issue is with the order of custom-set-variables form
relative to other forms that set customizable variables, then
use-package and other similar features should do what is needed to
make sure the order is correct.

Why cannot these existing features allow the solution of the problems
you describe?  Am I missing something?

> Then there's also the minor problem that using a configuration macro for
> customize usually means that the configuration is evaluated twice, which
> doesn't seem necessary.

Customize forms are evaluated multiple times anyway, and I don't see
any problem with that.  Sometimes it's even a feature.

Message #28 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Philip K." <philip <at> warpmail.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org, npostavs <at> gmail.com, 41473-done <at> debbugs.gnu.org
Subject: Re: bug#41473: Not saving all user options
Date: Sat, 27 Jun 2020 11:03:03 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Isn't this a problem to be solved by use-package or any other feature
> which works similarly?  Why do we have to have something in core for
> such a solution?
>
> If the issue is to disable saving a customized variable, then we
> already have the 'saved-value' property (and possibly other properties
> that have special meaning for custom.el) which can be manipulated to
> avoid the saving.

Ah, I didn't know that the property could inhibit saving! I've tried it
out, and it works as advertised. In that case the patch of course isn't
necessary. Sorry for the spam.

-- 
	Philip K.

Message #36 received at 41473 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Philip K." <philip <at> warpmail.net>
Cc: npostavs <at> gmail.com, 41473 <at> debbugs.gnu.org
Subject: Re: bug#41473: Not saving all user options
Date: Sat, 27 Jun 2020 12:23:17 +0300

> From: "Philip K." <philip <at> warpmail.net>
> Cc: npostavs <at> gmail.com, 41473-done <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org 
> Date: Sat, 27 Jun 2020 11:03:03 +0200
> 
> > If the issue is to disable saving a customized variable, then we
> > already have the 'saved-value' property (and possibly other properties
> > that have special meaning for custom.el) which can be manipulated to
> > avoid the saving.
> 
> Ah, I didn't know that the property could inhibit saving! I've tried it
> out, and it works as advertised. In that case the patch of course isn't
> necessary. Sorry for the spam.

No apologies are necessary.  I'm glad I could help you resolve the
issue.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.