bug#63891: 29.0.91; customize-save-variable should not save all variables if a custom file exists

[Mauro Aranda <maurooaranda@gmail.com>]

Hi Michael,

I looked at this more deeply, and I think I still don't understand
what's being asked of Custom in this use case.

First, let me just say that I'm aware of some problems with the
custom-save-all approach to modify the custom-file.  It was reported in
Bug#14150, but, while a different approach to fix Bug#14150 could also
solve this bug, I'm still not sure if the use case in files-x.el is a
supported one.

Both functions, connection-local-set-profile-variables and
connection-local-set-profiles modify 2 defcustoms, and want to tell
Custom that a change has happened.  The usual way to do that is to call
customize-set-variable, because the assumption is that the user used
some command provided by a package to modify the option.  And the
setting lasts for the session, of course.  But the surprise in Bug#62106
was that the users weren't requesting these changes in the options.  It
was done without a choice.

So, the code was changed to use custom-set-variables, which is used in
the custom-file and which means all the settings here should persist
from session to session.  So, in addition to modifying the user option
without a choice, the code then said that these modifications should be
saved.  That's even worse, which should show that custom-set-variables
is just the wrong tool here.  Of course, there's the workaround of
resetting saved-value to nil if possible.  But that just means that if
the user has a saved setting, he/she could possibly end up with all
settings added by a package too.  Of course, if Custom had other
approach for saving the settings, that would not happen, but it wouldn't
happen if the code weren't lying to Custom either.  And please note that
a similar workaround could be added if the code used
customize-set-variable still.

But here is my first question, if packages are going to be changing this
2 options without asking the user about it, why do the packages need to
lie to Custom saying that the user asked for that? Why don't just setq,
add-to-list or modify it some other way? At least that way Custom would
know the truth, the setting was changed outside of Customize.

That's why I don't understand what is the expectation about Custom here
(apart from being less naive when saving the custom-file).  The code is
modifying a user option and tells Custom that it was upon the user
request, when in fact it hasn't.

Finally, have you considered the approach of having the user option plus
another variable which packages should modify when desired? Then the
code could merge the user settings with the package settings.