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.