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

[Mauro Aranda]

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.