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

Previous Next

Package: emacs;

Reported by: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>

Date: Sun, 4 Jun 2023 12:37:01 UTC

Severity: normal

Found in version 29.0.91

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>
Cc: 63891 <at> debbugs.gnu.org
Subject: bug#63891: 29.0.91; customize-save-variable should not save all variables if a custom file exists
Date: Sun, 04 Jun 2023 15:56:49 +0300
> From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>
> 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.




This bug report was last modified 1 year and 230 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.