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

[Drew Adams <drew.adams@oracle.com>]

> 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.

Hi Mauro,

My 2 cents about such things -

1. Libraries can usefully modify user options.  They
just need to make users aware of this happening, so
that taking advantage of this is a user choice.

In particular, libraries can define commands whose
purpose includes changing option values - sometimes
even saving such changes immediately.  To me, this
isn't a no-no.  What is a no-no is changing an
option value behind a user's back, and a fortiori
saving such a change - big NO-NO.

Wrt your last paragraph above: That's the approach
that Emacs generally takes.  It's OK, though it's a
bit of a kludge.  More importantly, users can _want_
to modify an option value on the fly, as opposed to
modifying its non-option shadow/stand-in variable.

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.

This is a _convenience_ for users, not an obstacle:
be able to change behavior that's usually governed
by an option, without having Customize barf or save
the changes.  In effect, it's being able to use an
option temporarily as if it were not an option.

3. Emacs should also make available the ability for
`defvar' (or a new macro) to use the features of
`defcustom'.  In particular, this includes :set and
:type, and it includes the ability to persist the
value.

The difference between this and `defcustom' is that
uch variables aren't recognized by Emacs as user
options.  Users can't use the Customize UI or
`set-variable' with such vars.  `C-h v' provides no
`customize' link, etc.
___

#3 is maybe the most relevant to the points you
raised, but I also wanted to mention #1 and #2.

I proposed #3 to emacs-devel@gnu.org back in 2009:

https://lists.gnu.org/archive/html/emacs-devel/2009-10/msg00668.html

I sent a patch for #3 as bug #27348 (closed by Lars,
saying that no one would want such a feature):

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27348

That patch, with a couple trivial tweaks, is still
valid against Emacs 29, I believe.

It adds keyword `:not-custom-var' to `defcustom'.
If its value is non-`nil' then the variable doesn't
satisfy `custom-variable-p', which means it's _not
available for interactive use_ (completion,
`set-variable', `apropos-user-option' output, etc.).
IOW, such a variable is for code more than for user
configuration.

The patch also defines macro `defvarc', which is
just `defmacro' with `:not-custom-var' set to `t'.

The `defcustom' keywords etc. could have just been
added to `defvar' for optional use.  I defined a
separate macro just to not interfere with any
existing uses of `defvar'.

In sum, this uncouples interactive customization
from the other features that Customize offers, in
particular, type-checking and persistence, and it
provides those features for non-option variables.

The ability to type-check, provide `:set' and
`:initialize' trigger functions, automatically
`:require' libraries, add links to doc, associate
with one or more `:groups', etc.  These are useful
things to be able to do with at least some defvars,
not just with defcustoms.

Similarly, the ability to persist non-option vars
in a user's custom file can be useful.  This alone
is a frequent question, to which the answer has
been `savehist-additional-variables', `desktop.el',
or Bookmark+ variable-list bookmarks.

The patch also includes a macro `with-user-vars',
which temporarily lets a set of variables be
customizable.  That is, it lets you treat a
`defvarc' variable as if it were a `defcustom'
option.  So if you want, you can use the Customize
UI to change a defvarc's value, or define commands
that use (e.g. complete) `defvarc' variable names.