From: Drew Adams <drew.adams@oracle.com>
To: 31558@debbugs.gnu.org
Subject: bug#31558: 27.0; `custom-file' settings messed up by Emacs 27
Date: Tue, 22 May 2018 12:04:04 -0700 (PDT) [thread overview]
Message-ID: <5cd8f30c-a341-40c9-bb1f-441425e1a160@default> (raw)
Admittedly, this is probably not a problem that others will run into
often. But it is quite annoying for me.
I think the problem was introduced in Emacs 27, but I'm not positive.
This is the problem:
If I update a user option and then save the new value, it is saved to my
`custom-file', as usual. But thereafter my `custom-file' cannot be
loaded by Emacs 20, because of these two entries that have been updated:
'(tramp-default-method "ftp" nil (tramp))
'(tramp-verbose 9 nil (tramp))
I did not modify or ask to save those two options. Their values remain
the same as they were. What has happened is that Emacs has now added
"nil (tramp)", and those additional elements in the list make Emacs 20
choke, because library `tramp' does not exist in Emacs 20.
Signaling: (file-error "Cannot open load file" "tramp")
require(tramp)
mapcar(require (tramp))
custom-set-variables(... (tramp-debug-buffer t)
(tramp-default-method "ftp" nil (tramp))
(tramp-verbose 9 nil (tramp)) ...)
But why must Emacs now add that "nil (tramp)" to my custom settings?
Must defining the option value require the library?
I have no other case of an option where such a require argument is
inserted. And I need not use Tramp at all, for these options to get
updated this way.
Should Emacs (e.g. 27) be doing that systematically? If it should, then
what's the best way for me to prevent it from doing that, for my use
case?
(In fact, in Emacs 20, the doc string for `custom-set-variables' does
not even mention the possibility of an entry having a 4th argument,
REQUEST, but the code for that function does handle it, as
`custom-requests'.)
In GNU Emacs 27.0.50 (build 3, x86_64-w64-mingw32)
of 2018-03-21
Repository revision: e70d0c9e66d7a8609450b2889869d16aeb0363b5
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install -C 'CFLAGS=-O2 -static -g3''
next reply other threads:[~2018-05-22 19:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 19:04 Drew Adams [this message]
2018-05-23 9:07 ` bug#31558: 27.0; `custom-file' settings messed up by Emacs 27 Michael Albinus
2018-05-23 14:07 ` Drew Adams
2018-05-23 14:50 ` Michael Albinus
2018-05-23 15:47 ` Drew Adams
2018-05-23 18:05 ` Michael Albinus
2018-05-23 18:15 ` Drew Adams
2018-05-23 18:22 ` Michael Albinus
2018-05-23 19:17 ` Drew Adams
2018-05-24 12:43 ` Michael Albinus
2018-05-24 13:47 ` Drew Adams
2018-05-24 13:56 ` Michael Albinus
2018-05-24 14:44 ` Drew Adams
2018-05-24 14:59 ` Michael Albinus
2018-05-24 15:03 ` Drew Adams
2018-05-29 8:11 ` Michael Albinus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5cd8f30c-a341-40c9-bb1f-441425e1a160@default \
--to=drew.adams@oracle.com \
--cc=31558@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).