bug#41473: Not saving all user options

["Philip K." <philip@warpmail.net>]

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.