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

From: Eli Zaretskii <[email-masked]>
Date: Sun, 04 Jun 2023 15:56:49 +0300

> From: Jimmy Yuen Ho Wong <[email-masked]>
> Date: Sun, 04 Jun 2023 13:36:30 +0100
> 
> 
> As a discussion from bug #63300, it appears this long standing
> undocumented behavior of `custom-save-variable` is coming into conflict
> with the introduction of `connection-local-*` variables being user
> customizable and the fact that Tramp in Emacs 29 sets them on
> load. Here's a scenario where the combination of these behaviors results
> in one too many surprises:
> 
> 0. (setf custom-file "~/.emacs.d/custom.el")
> 1. M-x load-library tramp (or install a package that transitively
> requires tramp, without the user knowning)
> 2. Now `connection-local-profile-alist` and
> `connection-local-criteria-alist` are set by
> `hack-connection-local-variables-apply`.
> 3. M-x list-packages
> 4. Installs a new package
> 5. Now in addition to `package-selected-packages` being updated, 2
> gigantic variables are also saved. Since these connection-local
> variables are highly machine, application and connection dependent,
> saving them into the custom file will make it very annoying to be shared
> across multiple machines. This violates the principle of least
> astonishment.

I think the connection-local variables should be simple variables,
initialized from corresponding user options.  Then Tramp could hack
the variables without fear of clobbering user customizations.

Michael, can this be done on emacs-29 safely enough?

> Expectation:
> 
> `custom-save-variable` should only save the value of one variable
> regardless of whether a custom file exists.

How is custom-save-variable involved in the above scenario?

And what is custom-save-variable? did you mean customize-save-variable
instead?  That one does save just one variable, the one you type at
the prompt.