bug#41473: Not saving all user options

bug#41473: Not saving all user options

[Noam Postavsky]

severity 41473 wishlist
quit

"Philip K." <philip@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.

bug#41473: Not saving all user options

[Philip K.]

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


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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-inhibiting-a-user-option-from-being-saved.patch --]
[-- Type: text/x-diff, Size: 1591 bytes --]

From 07097f7bb79e5014ceafcb02563c173938e079bc Mon Sep 17 00:00:00 2001
From: Philip K <philip@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

bug#41473: Not saving all user options

[Eli Zaretskii]

> From: "Philip K." <philip@warpmail.net>
> Date: Fri, 26 Jun 2020 21:59:51 +0200
> Cc: 41473@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.

bug#41473: Not saving all user options

[Philip K.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Philip K." <philip@warpmail.net>
>> Date: Fri, 26 Jun 2020 21:59:51 +0200
>> Cc: 41473@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.

bug#41473: Not saving all user options

[Eli Zaretskii]

> From: "Philip K." <philip@warpmail.net>
> Cc: npostavs@gmail.com, 41473@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.

bug#41473: Not saving all user options

[Philip K.]

Eli Zaretskii <eliz@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.

bug#41473: Not saving all user options

[Eli Zaretskii]

> From: "Philip K." <philip@warpmail.net>
> Cc: npostavs@gmail.com, 41473-done@debbugs.gnu.org, bug-gnu-emacs@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.