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

[Mauro Aranda <maurooaranda@gmail.com>]

On 28/10/23 23:20, Drew Adams wrote:
 >>  > 2. Emacs should make available features I noted in
 >>  > previous posts, such as a function to consider a
 >>  > change to an option value (by program) to not be a
 >>  > change.  This lets code change a value but not
 >>  > have Customize consider that a change has been
 >>  > made - so the change won't be saved automatically
 >>  > or reported as having occurred.
 >>
 >> I wonder what does this mean in terms of the
 >> possible states for a user option.  AFAICT,
 >> none of the current possible states (STANDARD,
 >> SAVED, CHANGED, SET) fit in your description.
 >>
 >> STANDARD: No, standard value and current value
 >>           don't match.
 >> SAVED:    No, that setting wasn't saved.
 >> CHANGED:  No, because you're saying that Custom
 >>           shouldn't consider the change.
 >> SET:      No, because the code needs to use
 >>           customize-set-variable, but that
 >>           wouldn't be Custom ignoring the change.
 >
 > I use my library `cus-edit+.el', which changes
 > some of the `cus-edit.el' code.  See, e.g.,
 > function `custom-consider-variable-unchanged'.
 > Doc string:
 >
 >   Consider this variable as being unchanged now.
 >   This does not save the current value; it just
 >   considers the value to be unchanged.  If no
 >   further changes are made to this variable, then
 >   after doing this, `customize-customize' will not
 >   display this variable, since it was considered
 >   unchanged.

'customize-customized', right?

 > The cus-edit+.el code is here:
 >
 > http://www.emacswiki.org/emacs-en/download/cus-edit%2b.el

I tried to visit this link with eww, but got 404 Not Found.

 > And here is some info about it:
 >
 > http://www.emacswiki.org/CustomizingAndSaving#CustomizePlus

Same here.

Anyway, I read custom-consider-variable-unchanged, and it looks to me
that it would have the same problem when saving an unrelated variable,
because of the way custom-save-all works.  I want to work on improving
the saving mechanism so that problem disappears, but ISTM that this
bug report is about a different bug: a misuse of custom-set-variables.

 > About considering some customized state to be
 > "unchanged", see this post to bug 19328 thread.
 >
 > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19328#47

Thank you.  I read the "Dealing with Spurious Changes" section from
cus-edit+.el.  Part 2 and Part 3 sound interesting to me.  It seems to
me that adding an ignore mechanism would be useful, in general.

 > I don't claim that what I did in `cus-edit+.el'
 > is the only or the best way to fix the problems
 > it addresses.  It might be a starting point for
 > someone with a better idea or understanding of
 > the custom code/behavior.

It's certainly useful to me to know about your approach.

I guess at this point I need to hear from Michael to understand better
about this 2 defcustoms in particular, and what are the expectations
after modifying them.  I certainly wish the code goes back to using
customize-set-variable or something similar, rather than
custom-set-variables.