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

[Drew Adams]

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

The cus-edit+.el code is here:

http://www.emacswiki.org/emacs-en/download/cus-edit%2b.el

And here is some info about it:

http://www.emacswiki.org/CustomizingAndSaving#CustomizePlus

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

See this part of the post: "Dealing with Spurious
Changes, 3: Consider Unchanged."

This lets Customize know that the current values
(options or faces) are to be treated as if they
were saved, but without actually saving them to
your custom file.

That way, your custom file is not polluted with
things that you're not really concerned with, yet
you're not bothered by seeing such fictitious
changes show up each time you check for changes.

Unlike ignoring changes to certain preferences
(see below), and really saving current values,
`Consider Unchanged' isn't a persistent change.

You can use it any time to "reset" the change
counter for given preferences, so the current
change is considered the new base value (as if
it were saved), and any further changes you make
to them will then show up as changes, using
`customize-unsaved'.

The "ignoring changes" mentioned above is another
possibility (see "Dealing with Spurious Changes,
2: Ignore" in the same bug 19328 message).  It's
appropriate for some preferences that you might
change often and temporarily.  You can add such
options to a list, `customize-customized-ignore'.
The effect is to make `customize-unsaved' ignore
them.

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.

>  > 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.
> 
> This sounds interesting.
> 
>  > 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
...
>  > 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.
> 
> Thank you for the links and the explanation.  I'll take the time to read
> them.
> 
> Just by reading your explanation, I don't think I understand if just by
> using something like your description of 'defvarc' would solve the issue
> of having to combine user's customizations with a package setting by
> using two different variables.

I don't know what particular issues it might solve.
Its point is just to separate the ability to have
`defcustom' features (type-checking, initialization,
persistence, etc.) without interfering with a user's
use of the Customize UI etc.

HTH.