Actually, I take it back. customize-save-variable only saves variables that have the saved-value symbol property set. This property is normally set by customize when it is saved to the custom file. Something in Tramp is setting this property without saving the variable values to the custom file or going through customize. In fact, you can see it via M-x customize-option connection-local-criteria-alist. The value will be shown as SAVED. In addition, setting `enable-connection-local-variables` to nil early in early-init.el has no effect, the variable is still set on load. Both of this behavior violate what is documented in the docstring and https://www.gnu.org/software/emacs/manual/html_node/elisp/Standard-Properties.html. If you must, enable-conneciton-local-variables should be respected, and if you must, set the theme-value property on these connection-local variables instead of saved-value so custom-save-all will not save them. On 4 Jun 2023 at 1:23 PM +0100, Jimmy Wong , wrote: > I’ll file a separate bug. You can close this one. Thanks. > On 4 Jun 2023 at 1:21 PM +0100, Michael Albinus , wrote: > > Jimmy Wong writes: > > > > Hi, > > > > > Well, yes, I consider this a poorly considered “feature”, or arguably > > > a bug, for exactly the reason you said, they are local to connections > > > and machines, and thus highly variable. > > > > Not really. They exist for the reason that a user can override the > > default values offered by Tramp. This I would call a user option. > > > > Tramp has a lot of further host specific data, which are all kept in > > variables. > > > > > We can probably argue whether this is a bug in tramp or a bug in > > > customize-save-variable tho (why on earth does the act of saving a > > > single variable value saves all customized values if a custom file > > > exists?) > > > > I agree with the latter. > > > > Best regards, Michael.