GNU bug report logs -
#79124
emacs -Q doesn't give me a clean slate
Previous Next
To reply to this bug, email your comments to 79124 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 30 Jul 2025 00:00:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 30 Jul 2025 00:00:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Over the years Emacs has come slurp more and more files from the user's
home directory, which is fine except that 'emacs -Q' is supposed to
suppress this sort of thing, partly to help debugging so that one can
easily have a clean Emacs to test with.
Unfortunately, nowadays 'emacs -Q' now has some questionable accesses to
configuration files or caches. I did an "cd /tmp" followed by an "strace
emacs -Q -nw" using Emacs master (on Fedora 42) where I immediately
typed C-x C-c to exit, and found that Emacs accessed or attempted to
access the following files under my home directory. -Q should disable
these accesses; or if -Q is not the right way to do that, there should
be an easy way to tell Emacs "start with a clean slate; don't access any
of my startup configuration or cache or whatever".
.abbrev_defs
.emacs.d
.emacs.d/
.emacs.d/./
.emacs.d/abbrev_defs
.emacs.d/auto-save-list/.saves-67042-penguin.cs.ucla.edu~
.emacs.d/eln-cache/
.emacs.d/eln-cache/31.0.50-6ea53a16/
.emacs.d/eln-cache/31.0.50-6ea53a16/ansi-color-75eac800-a71f27cf.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/ansi-osc-b447f6a8-8febe2b9.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/byte-opt-9c5f25f5-7cc5ddb7.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/bytecomp-12882072-8edd60a1.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/cl-lib-8b938900-a571fbf6.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/cl-loaddefs-310c8015-a1d7aa30.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/comint-faef15ad-bfa1fb2f.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/comp-common-6e17f702-933f2808.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/comp-run-a15747ee-efc134fc.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/compile-91e1c2a0-9cbeba37.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/gv-e0cf7478-71e25e63.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/ring-bff0b981-036e8192.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/rx-627d8c83-9aae5e83.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/subr-x-02dfef32-97626417.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/text-property-search-db1383f6-03526671.eln
.emacs.d/eln-cache/31.0.50-6ea53a16/time-date-40951a48-4999dc2b.eln
.terminfo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 30 Jul 2025 12:18:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 29 Jul 2025 16:59:23 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> Over the years Emacs has come slurp more and more files from the user's
> home directory, which is fine except that 'emacs -Q' is supposed to
> suppress this sort of thing, partly to help debugging so that one can
> easily have a clean Emacs to test with.
>
> Unfortunately, nowadays 'emacs -Q' now has some questionable accesses to
> configuration files or caches. I did an "cd /tmp" followed by an "strace
> emacs -Q -nw" using Emacs master (on Fedora 42) where I immediately
> typed C-x C-c to exit, and found that Emacs accessed or attempted to
> access the following files under my home directory. -Q should disable
> these accesses; or if -Q is not the right way to do that, there should
> be an easy way to tell Emacs "start with a clean slate; don't access any
> of my startup configuration or cache or whatever".
>
> .abbrev_defs
> .emacs.d
> .emacs.d/
> .emacs.d/./
> .emacs.d/abbrev_defs
This is because we load abbrevs at startup, even under -Q. That was
added in Nov 2001:
commit ac3186fd96de9332bbeb4c7bf1f7ac66de26752a
Author: Richard M. Stallman <rms <at> gnu.org>
AuthorDate: Sun Nov 11 01:53:31 2001 +0000
Commit: Richard M. Stallman <rms <at> gnu.org>
CommitDate: Sun Nov 11 01:53:31 2001 +0000
(command-line): Read standard abbrev
file (abbrev-file-name), if it exists.
I couldn't find any discussion why this was added. Perhaps Richard
remembers why he added that, and whether doing this under -Q was on
purpose or an omission?
> .emacs.d/auto-save-list/.saves-67042-penguin.cs.ucla.edu~
This is because we want to support recovering crashed sessions, even
with -Q. Not sure this is wrong.
> .emacs.d/eln-cache/
> .emacs.d/eln-cache/31.0.50-6ea53a16/
> .emacs.d/eln-cache/31.0.50-6ea53a16/ansi-color-75eac800-a71f27cf.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/ansi-osc-b447f6a8-8febe2b9.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/byte-opt-9c5f25f5-7cc5ddb7.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/bytecomp-12882072-8edd60a1.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/cl-lib-8b938900-a571fbf6.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/cl-loaddefs-310c8015-a1d7aa30.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/comint-faef15ad-bfa1fb2f.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/comp-common-6e17f702-933f2808.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/comp-run-a15747ee-efc134fc.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/compile-91e1c2a0-9cbeba37.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/gv-e0cf7478-71e25e63.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/ring-bff0b981-036e8192.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/rx-627d8c83-9aae5e83.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/subr-x-02dfef32-97626417.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/text-property-search-db1383f6-03526671.eln
> .emacs.d/eln-cache/31.0.50-6ea53a16/time-date-40951a48-4999dc2b.eln
These are natively-compiled Lisp packages. I'm guessing that, since
you've started a -nw session, Emacs needed to load the support library
for the terminal you are using, which triggered the JIT native
compilation of that library and all the libraries it depends on. So
this is normal, and has nothing to do with -Q: Emacs must load the
Lisp packages needed for its operation.
> .terminfo
I guess this is from some curses library, not from Emacs per se.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 30 Jul 2025 14:12:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 79124 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 30 Jul 2025 15:15:49 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> Date: Tue, 29 Jul 2025 16:59:23 -0700
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>>
>> Over the years Emacs has come slurp more and more files from the user's
>> home directory, which is fine except that 'emacs -Q' is supposed to
>> suppress this sort of thing, partly to help debugging so that one can
>> easily have a clean Emacs to test with.
>>
>> Unfortunately, nowadays 'emacs -Q' now has some questionable accesses to
>> configuration files or caches. I did an "cd /tmp" followed by an "strace
>> emacs -Q -nw" using Emacs master (on Fedora 42) where I immediately
>> typed C-x C-c to exit, and found that Emacs accessed or attempted to
>> access the following files under my home directory. -Q should disable
>> these accesses; or if -Q is not the right way to do that, there should
>> be an easy way to tell Emacs "start with a clean slate; don't access any
>> of my startup configuration or cache or whatever".
>>
>> .abbrev_defs
>> .emacs.d
>> .emacs.d/
>> .emacs.d/./
>> .emacs.d/abbrev_defs
We sometimes also read from .emacs.d/network-security.data under -Q,
which can be annoying when testing TLS code. I canʼt remember exactly
the cause, since Iʼve long switched to "HOME=/tmp/emacs src/emacs -Q".
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 30 Jul 2025 15:31:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Richard Stallman <rms <at> gnu.org>,
> 79124 <at> debbugs.gnu.org
> Date: Wed, 30 Jul 2025 16:11:15 +0200
>
> We sometimes also read from .emacs.d/network-security.data under -Q,
Not at startup time, right? You are talking about calling some
network-related APIs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 30 Jul 2025 15:34:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 79124 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 30 Jul 2025 18:29:40 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Richard Stallman <rms <at> gnu.org>,
>> 79124 <at> debbugs.gnu.org
>> Date: Wed, 30 Jul 2025 16:11:15 +0200
>>
>> We sometimes also read from .emacs.d/network-security.data under -Q,
Eli> Not at startup time, right? You are talking about calling some
Eli> network-related APIs.
Right. But itʼs still surprising that Emacs reads from ~/.emacs.d when
-Q is specified.
Basically it happens whenever `nsm-verify-connection' calls
`nsm-host-settings'. We could add a check for "-Q" there.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 30 Jul 2025 16:05:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: eggert <at> cs.ucla.edu, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> Date: Wed, 30 Jul 2025 17:33:26 +0200
>
> >>>>> On Wed, 30 Jul 2025 18:29:40 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>
> >> From: Robert Pluim <rpluim <at> gmail.com>
> >> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Richard Stallman <rms <at> gnu.org>,
> >> 79124 <at> debbugs.gnu.org
> >> Date: Wed, 30 Jul 2025 16:11:15 +0200
> >>
> >> We sometimes also read from .emacs.d/network-security.data under -Q,
>
> Eli> Not at startup time, right? You are talking about calling some
> Eli> network-related APIs.
>
> Right. But itʼs still surprising that Emacs reads from ~/.emacs.d when
> -Q is specified.
>
> Basically it happens whenever `nsm-verify-connection' calls
> `nsm-host-settings'. We could add a check for "-Q" there.
OTOH, it's quite annoying to type the same responses to the NSM
prompts when trying stuff in "emacs -Q".
There is "emacs -D", which perhaps could be more "pristine". Patches
welcome.
That said, these options are of interest only to Emacs hackers.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 30 Jul 2025 16:24:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 79124 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 30 Jul 2025 19:03:25 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: eggert <at> cs.ucla.edu, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
>> Date: Wed, 30 Jul 2025 17:33:26 +0200
>>
>> >>>>> On Wed, 30 Jul 2025 18:29:40 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>>
>> >> From: Robert Pluim <rpluim <at> gmail.com>
>> >> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Richard Stallman <rms <at> gnu.org>,
>> >> 79124 <at> debbugs.gnu.org
>> >> Date: Wed, 30 Jul 2025 16:11:15 +0200
>> >>
>> >> We sometimes also read from .emacs.d/network-security.data under -Q,
>>
Eli> Not at startup time, right? You are talking about calling some
Eli> network-related APIs.
>>
>> Right. But itʼs still surprising that Emacs reads from ~/.emacs.d when
>> -Q is specified.
>>
>> Basically it happens whenever `nsm-verify-connection' calls
>> `nsm-host-settings'. We could add a check for "-Q" there.
Eli> OTOH, it's quite annoying to type the same responses to the NSM
Eli> prompts when trying stuff in "emacs -Q".
Yes, but if you save the result, then the 2nd time you run the test
you donʼt get prompted, and you wonder what you broke :-)
Eli> There is "emacs -D", which perhaps could be more "pristine". Patches
Eli> welcome.
Eli> That said, these options are of interest only to Emacs hackers.
Yes. The HOME trick is enough for me.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 30 Jul 2025 17:03:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-07-30 09:03, Eli Zaretskii wrote:
> OTOH, it's quite annoying to type the same responses to the NSM
> prompts when trying stuff in "emacs -Q".
>
> There is "emacs -D", which perhaps could be more "pristine". Patches
> welcome.
Thanks for looking into it. As someone who merely wants to run Emacs in
a clean state I find all these options confusing. For example I didn't
know about -D, and I had forgotten about the $HOME trick. It would be
convenient to have an easy way to do all this stuff.
How about a new option, say -R or --really-quick, that causes Emacs to
omit all this setup information so as to get a clean slate? It would
cause Emacs to not access anything under $HOME during setup, as well as
by doing everything that -Q and -D do, along with any similar options
(--no-desktop, --no-build-details, anything else?).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Thu, 31 Jul 2025 04:27:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 30 Jul 2025 10:02:35 -0700
> Cc: rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-07-30 09:03, Eli Zaretskii wrote:
> > OTOH, it's quite annoying to type the same responses to the NSM
> > prompts when trying stuff in "emacs -Q".
> >
> > There is "emacs -D", which perhaps could be more "pristine". Patches
> > welcome.
>
> Thanks for looking into it. As someone who merely wants to run Emacs in
> a clean state I find all these options confusing. For example I didn't
> know about -D, and I had forgotten about the $HOME trick. It would be
> convenient to have an easy way to do all this stuff.
One only knows about that if one needs it. This stuff is only useful
for Emacs hackers.
> How about a new option, say -R or --really-quick, that causes Emacs to
> omit all this setup information so as to get a clean slate?
I'd prefer not to add another startup option. Here, you didn't even
know about -D, so what are the chances someone else will know about
this new option?
Would it be possible to make -D omit those few accesses that it
doesn't now?
> It would
> cause Emacs to not access anything under $HOME during setup, as well as
> by doing everything that -Q and -D do, along with any similar options
> (--no-desktop, --no-build-details, anything else?).
Well, "access nothing under $HOME" won't work with natively-compiled
Emacs, because it needs to access files in ~/.emacs.c/eln-cache/. The
"-nw" session always does that, and even without -nw Emacs sometimes
does need to access that directory. But otherwise, yes, we could
avoid loading abbrevs and auto-save-list files (which AFAIU are the
only other files read at startup under -Q). Not sure what you want to
do about .terminfo.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Thu, 31 Jul 2025 05:06:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-07-30 21:25, Eli Zaretskii wrote:
> I'd prefer not to add another startup option. Here, you didn't even
> know about -D, so what are the chances someone else will know about
> this new option?
The point is that one needs to use multiple options now, along with
setting at least one environment variable at least part of the time, and
it's easy to forget this stuff.
How about -QQ? That'd be easy to remember. The idea is to get a simple
setup that yields reproducible results regardless of user.
> Would it be possible to make -D omit those few accesses that it
> doesn't now?
I assume it would be. I don't know how -D works, though.
> Well, "access nothing under $HOME" won't work with natively-compiled
> Emacs, because it needs to access files in ~/.emacs.c/eln-cache/.
? I just now ran natively-compiled Emacs with HOME set to a nonexistent
directory, and it worked fine. I was using 'emacs -D -Q -nw' on Fedora
42 x86-64.
> Not sure what you want to
> do about .terminfo.
I don't want to load it either, because it makes tests irreproducible.
I'm sure this could be arranged somehow.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Thu, 31 Jul 2025 05:47:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 30 Jul 2025 22:05:31 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-07-30 21:25, Eli Zaretskii wrote:
>
> > I'd prefer not to add another startup option. Here, you didn't even
> > know about -D, so what are the chances someone else will know about
> > this new option?
>
> The point is that one needs to use multiple options now, along with
> setting at least one environment variable at least part of the time, and
> it's easy to forget this stuff.
>
> How about -QQ? That'd be easy to remember. The idea is to get a simple
> setup that yields reproducible results regardless of user.
It's slightly better, but I'm not sure it's better than "-Q -D".
> > Would it be possible to make -D omit those few accesses that it
> > doesn't now?
>
> I assume it would be. I don't know how -D works, though.
It sets emacs-basic-display non-nil in startup.el.
> > Well, "access nothing under $HOME" won't work with natively-compiled
> > Emacs, because it needs to access files in ~/.emacs.c/eln-cache/.
>
> ? I just now ran natively-compiled Emacs with HOME set to a nonexistent
> directory, and it worked fine. I was using 'emacs -D -Q -nw' on Fedora
> 42 x86-64.
"Worked fine" in what sense? Are you saying it didn't need to
natively-compile anything? Are you sure?
When Emacs starts with -nw, it needs to load a library from lisp/term/
that corresponds to the terminal (if there is such a library). If it
cannot find a .eln file for that, it will attempt to compile it
natively, and that loads a bunch of Lisp packages needed for the
compilation. In a normally-configured system, all those files are in
~/.emacs.c/eln-cache/.
> > Not sure what you want to
> > do about .terminfo.
>
> I don't want to load it either, because it makes tests irreproducible.
> I'm sure this could be arranged somehow.
Fine, but this is out of scope of Emacs, no? When and why is this
accessed? Maybe some special terminal type could avoid that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Thu, 31 Jul 2025 14:44:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-07-30 22:45, Eli Zaretskii wrote:
> It's slightly better, but I'm not sure it's better than "-Q -D".
I could live with -Q -D if it was a clean slate, though it's not now. If
there are good reasons for it to not be a clean slate, I'd like a simple
way to get one.
>> I don't know how -D works, though.
>
> It sets emacs-basic-display non-nil in startup.el.
Apparently that's not enough to get rid of all display-related data
slurping from $HOME. Is it the intent of -D to stop such slurping?
>
>>> Well, "access nothing under $HOME" won't work with natively-compiled
>>> Emacs, because it needs to access files in ~/.emacs.c/eln-cache/.
>>
>> ? I just now ran natively-compiled Emacs with HOME set to a nonexistent
>> directory, and it worked fine. I was using 'emacs -D -Q -nw' on Fedora
>> 42 x86-64.
>
> "Worked fine" in what sense? Are you saying it didn't need to
> natively-compile anything? Are you sure?
Oh, I assume it tried to natively compile. And it put up a *Warning*
buffer with blue-colored BLACK SQUARE (U+25A0) saying " ■ Warning
(initialization): Unable to create `user-emacs-directory' (~/.emacs.d/).
Any data that would normally be written there may be lost! If you never
want to see this message again, customize the variable
`user-emacs-directory-warning'." But I didn't see any problems after that.
Presumably a new -QQ option would disable that part of the startup.
>>> Not sure what you want to
>>> do about .terminfo.
>>
>> I don't want to load it either, because it makes tests irreproducible.
>> I'm sure this could be arranged somehow.
>
> Fine, but this is out of scope of Emacs, no? When and why is this
> accessed? Maybe some special terminal type could avoid that?
Yes, something like that, either as part of -QQ or of "-Q -D" (though I
don't know whether it'd belong to -Q or to -D).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Thu, 31 Jul 2025 15:54:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 31 Jul 2025 07:43:09 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-07-30 22:45, Eli Zaretskii wrote:
>
> > It's slightly better, but I'm not sure it's better than "-Q -D".
>
> I could live with -Q -D if it was a clean slate, though it's not now. If
> there are good reasons for it to not be a clean slate, I'd like a simple
> way to get one.
>
> >> I don't know how -D works, though.
> >
> > It sets emacs-basic-display non-nil in startup.el.
>
> Apparently that's not enough to get rid of all display-related data
> slurping from $HOME. Is it the intent of -D to stop such slurping?
Of course, it's not enough: we need to change the code. I was just
telling you how -D takes its effect, because I thought that was what
you were asking about.
> >>> Well, "access nothing under $HOME" won't work with natively-compiled
> >>> Emacs, because it needs to access files in ~/.emacs.c/eln-cache/.
> >>
> >> ? I just now ran natively-compiled Emacs with HOME set to a nonexistent
> >> directory, and it worked fine. I was using 'emacs -D -Q -nw' on Fedora
> >> 42 x86-64.
> >
> > "Worked fine" in what sense? Are you saying it didn't need to
> > natively-compile anything? Are you sure?
>
> Oh, I assume it tried to natively compile. And it put up a *Warning*
> buffer with blue-colored BLACK SQUARE (U+25A0) saying " ■ Warning
> (initialization): Unable to create `user-emacs-directory' (~/.emacs.d/).
> Any data that would normally be written there may be lost! If you never
> want to see this message again, customize the variable
> `user-emacs-directory-warning'." But I didn't see any problems after that.
So this is not really "working fine". Emacs with native compilation
does need to access files under the user's home directory, at least in
the -nw case and if it needs to load some Lisp.
> Presumably a new -QQ option would disable that part of the startup.
You want to disable JIT native-compilation as well? Why?
> >>> Not sure what you want to
> >>> do about .terminfo.
> >>
> >> I don't want to load it either, because it makes tests irreproducible.
> >> I'm sure this could be arranged somehow.
> >
> > Fine, but this is out of scope of Emacs, no? When and why is this
> > accessed? Maybe some special terminal type could avoid that?
>
> Yes, something like that, either as part of -QQ or of "-Q -D" (though I
> don't know whether it'd belong to -Q or to -D).
If you want to have a working Emacs that can edit stuff, then
disregarding Terminfo might be a problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Thu, 31 Jul 2025 16:20:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-07-31 08:53, Eli Zaretskii wrote:
> So this is not really "working fine". Emacs with native compilation
> does need to access files under the user's home directory, at least in
> the -nw case and if it needs to load some Lisp.
I don't see why. If native-compiled modules aren't available Emacs can
get by with byte-compiled or even source files. And if that doesn't
suffice (why not?) Emacs can create a /tmp cache directory and use that.
At any rate, I'm still puzzled by the idea that Emacs doesn't work now
in this situation. What's not working (other than the diagnostic, which
we can easily suppress)? For example, if I run this shell command on Fedora:
HOME=/nosuch emacs -nw -D -Q
I see that Emacs attempts to access /nosuch/.emacs.d/eln-cache and a
bunch of other files under /nosuch, the accesses all fail, and Emacs
keeps chugging along. What am I missing? (And why does it matter whether
I use -nw?)
>> Presumably a new -QQ option would disable that part of the startup.
>
> You want to disable JIT native-compilation as well? Why?
I don't necessarily want to disable it. I merely want Emacs to not rely
on any cache in my home directory. Emacs can do whatever jitting it
likes, so long as jits from a clean slate.
> If you want to have a working Emacs that can edit stuff, then
> disregarding Terminfo might be a problem.
For this use case that's a feature not a problem. When testing, I don't
want Emacs to consult the user's private ~/.terminfo file even if one
exists, because I want the run to be reproducible independent of user.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Fri, 01 Aug 2025 05:55:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 31 Jul 2025 09:19:20 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-07-31 08:53, Eli Zaretskii wrote:
>
> > So this is not really "working fine". Emacs with native compilation
> > does need to access files under the user's home directory, at least in
> > the -nw case and if it needs to load some Lisp.
>
> I don't see why. If native-compiled modules aren't available Emacs can
> get by with byte-compiled or even source files. And if that doesn't
> suffice (why not?) Emacs can create a /tmp cache directory and use that.
Because that's not how the relevant code is written, and I don't see
why we would need to make such significant changes in that tricky part
of Emacs just to support a requirement to not access any files in the
user's home directory. This kind of operation is a very niche
feature, useful for very few Emacs users, so making deep changes in
code that took us 3 major releases to get right is not something I'm
glad to do.
I don't object to small changes in support of what you want, but
that's it. There's no way Emacs built with native-compilation can
start without looking up *.eln files and/or writing *.eln files,
unless you ensure with 110% probability that it doesn't need to load
any Lisp that is not preloaded. Ensuring that is not easy (and not
possible at all in the -nw case), but that's the only way it's going
to work.
> At any rate, I'm still puzzled by the idea that Emacs doesn't work now
> in this situation. What's not working (other than the diagnostic, which
> we can easily suppress)? For example, if I run this shell command on Fedora:
>
> HOME=/nosuch emacs -nw -D -Q
>
> I see that Emacs attempts to access /nosuch/.emacs.d/eln-cache and a
> bunch of other files under /nosuch, the accesses all fail, and Emacs
> keeps chugging along. What am I missing? (And why does it matter whether
> I use -nw?)
I explained why -nw matters: Emacs needs to load lisp/term/xterm.el
(or some other terminal-specific library). Since those libraries are
not preloaded, Emacs looks up their *.eln files, and if it doesn't
find them, it will load xterm.elc and attempt to natively-compile
xterm.el into xterm.eln, putting xterm.eln in ~/.emacs.d/eln-cache's
subdirectory (and then load it). That's what JIT compilation is
about.
> >> Presumably a new -QQ option would disable that part of the startup.
> >
> > You want to disable JIT native-compilation as well? Why?
>
> I don't necessarily want to disable it. I merely want Emacs to not rely
> on any cache in my home directory. Emacs can do whatever jitting it
> likes, so long as jits from a clean slate.
You can only achieve that if you modify native-comp-eln-load-path to
replace the first element by some temporary writable directory. This
should be done very early, I hope that early-init file is early enough
(but I haven't tried that). Otherwise, this is currently impossible,
and I'm not very interested in changing how JIT compilation works to
support your use case by default, because your use case is marginal
and not very important, and because that stuff runs at startup and is
quite delicate.
> > If you want to have a working Emacs that can edit stuff, then
> > disregarding Terminfo might be a problem.
>
> For this use case that's a feature not a problem. When testing, I don't
> want Emacs to consult the user's private ~/.terminfo file even if one
> exists, because I want the run to be reproducible independent of user.
I don't know what could be in ~/.terminfo, so I don't understand the
implications of that. If it could affect how the terminal performs
its functions, like moving the cursor or inserting/deleting text in
the screen, it could be important for the Emacs operation.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Sat, 02 Aug 2025 18:54:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-07-31 22:54, Eli Zaretskii wrote:
> I explained why -nw matters: Emacs needs to load lisp/term/xterm.el
> (or some other terminal-specific library). Since those libraries are
> not preloaded, Emacs looks up their *.eln files, and if it doesn't
> find them, it will load xterm.elc and attempt to natively-compile
> xterm.el into xterm.eln, putting xterm.eln in ~/.emacs.d/eln-cache's
> subdirectory (and then load it). That's what JIT compilation is
> about.
That's all fine, but the main point is that, -nw or not, everything
works for me despite there being no eln cache. Nothing goes wrong. Emacs
works fine other than spurious diagnostics that a new flag would
suppress. So I'm still puzzled as to why the eln cache is essential for
Emacs to operate.
Even if something (but what?) goes wrong for interactive use, my main
use case is -batch (for testing) where terminal-specific libraries
largely don't matter.
> if you modify native-comp-eln-load-path to
> replace the first element by some temporary writable directory. This
> should be done very early
That's doable and fairly simple, though I'm still puzzled as to why it's
needed.
Alternatively, Emacs could be taught to not trust any existing files in
the eln cache. That should be a simple change. Emacs probably has a
"don't trust" mode already for files generated by older versions, and
the mode just needs to be enabled for reproducible testing.
> I don't know what could be in ~/.terminfo, so I don't understand the
> implications of that.
I know what could be in ~/.terminfo, and it's definitely not important
for reproducible testing. It's worse than not important: it's
counterproductive.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Sat, 02 Aug 2025 19:30:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 2 Aug 2025 11:53:19 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-07-31 22:54, Eli Zaretskii wrote:
> > I explained why -nw matters: Emacs needs to load lisp/term/xterm.el
> > (or some other terminal-specific library). Since those libraries are
> > not preloaded, Emacs looks up their *.eln files, and if it doesn't
> > find them, it will load xterm.elc and attempt to natively-compile
> > xterm.el into xterm.eln, putting xterm.eln in ~/.emacs.d/eln-cache's
> > subdirectory (and then load it). That's what JIT compilation is
> > about.
>
> That's all fine, but the main point is that, -nw or not, everything
> works for me despite there being no eln cache. Nothing goes wrong. Emacs
> works fine other than spurious diagnostics that a new flag would
> suppress. So I'm still puzzled as to why the eln cache is essential for
> Emacs to operate.
Because Emacs writes there the *.eln files it produces at startup.
> > if you modify native-comp-eln-load-path to
> > replace the first element by some temporary writable directory. This
> > should be done very early
>
> That's doable and fairly simple, though I'm still puzzled as to why it's
> needed.
Because the default value of that variable has ~/.emacs.d/eln-cache as
its first element, whereas you want to avoid accessing the user's home
directory.
> Alternatively, Emacs could be taught to not trust any existing files in
> the eln cache. That should be a simple change. Emacs probably has a
> "don't trust" mode already for files generated by older versions, and
> the mode just needs to be enabled for reproducible testing.
I don't understand what you are saying here. The trust thing is for
security, so why would it be applicable to *.eln files?
> > I don't know what could be in ~/.terminfo, so I don't understand the
> > implications of that.
>
> I know what could be in ~/.terminfo, and it's definitely not important
> for reproducible testing. It's worse than not important: it's
> counterproductive.
Then maybe you also know how to force the curses libraries not to look
there? Again, this is not an Emacs problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Sun, 03 Aug 2025 15:53:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-02 12:28, Eli Zaretskii wrote:
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>> -nw or not, everything
>> works for me despite there being no eln cache. Nothing goes wrong. Emacs
>> works fine other than spurious diagnostics that a new flag would
>> suppress. So I'm still puzzled as to why the eln cache is essential for
>> Emacs to operate.
>
> Because Emacs writes there the *.eln files it produces at startup.
But Emacs doesn't do that. Under the scenario I gave, Emacs does not
write *.eln files as there's no place to write them: the cache directory
does not exist and cannot be created.
And Emacs still works fine. And this is better for testing, as test
results do not rely on the contents of the user's home directory.
> I don't understand what you are saying here. The trust thing is for
> security, so why would it be applicable to *.eln files?
I'm a bit fuzzy on exactly when Emacs refuses to load an *.eln file, but
whatever reason Emacs doesn't do it (security, API incompatibility,
wrong architecture, out of date with respect to source, ...) we can add
the new -QQ option as another reason not to do it. This should not be a
drastic change.
>>> I don't know what could be in ~/.terminfo, so I don't understand the
>>> implications of that.
>>
>> I know what could be in ~/.terminfo, and it's definitely not important
>> for reproducible testing. It's worse than not important: it's
>> counterproductive.
>
> Then maybe you also know how to force the curses libraries not to look
> there? Again, this is not an Emacs problem.
It's an Emacs problem only in that a bit of Emacs code needs to be added
to force the curses libraries not to look there.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Sun, 03 Aug 2025 16:11:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 3 Aug 2025 08:52:36 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-08-02 12:28, Eli Zaretskii wrote:
> >> From: Paul Eggert <eggert <at> cs.ucla.edu>
> >> -nw or not, everything
> >> works for me despite there being no eln cache. Nothing goes wrong. Emacs
> >> works fine other than spurious diagnostics that a new flag would
> >> suppress. So I'm still puzzled as to why the eln cache is essential for
> >> Emacs to operate.
> >
> > Because Emacs writes there the *.eln files it produces at startup.
>
> But Emacs doesn't do that. Under the scenario I gave, Emacs does not
> write *.eln files as there's no place to write them: the cache directory
> does not exist and cannot be created.
I don't know what exactly happened in your case, and you never
described all of those details. I'm telling you what Emacs is
programmed to do.
> And Emacs still works fine.
For some value of "fine". Since we don't know what happened (which
files it tried to compile, if it tried, and where, if anywhere, it
wrote the *.eln files), we also don't know exactly what kind of
"working Emacs" you got as result. That it succeeded to run some
simple commands doesn't necessarily mean it's a healthy session.
Maybe it is, maybe it isn't.
> And this is better for testing, as test results do not rely on the
> contents of the user's home directory.
Then your problem is solved, and we can stop this discussion, which
from my POV goes nowhere useful? I thought you were asking for some
code changes? If you are happy with what we have now, I'm fine with
that. Otherwise, I don't think I understand what are you trying to
say.
> > I don't understand what you are saying here. The trust thing is for
> > security, so why would it be applicable to *.eln files?
>
> I'm a bit fuzzy on exactly when Emacs refuses to load an *.eln file, but
> whatever reason Emacs doesn't do it (security, API incompatibility,
> wrong architecture, out of date with respect to source, ...) we can add
> the new -QQ option as another reason not to do it. This should not be a
> drastic change.
Sorry, I'm not interested. We already have enough knobs to disable
native compilation (they are described in the manual), and I see no
reason to add more.
> >>> I don't know what could be in ~/.terminfo, so I don't understand the
> >>> implications of that.
> >>
> >> I know what could be in ~/.terminfo, and it's definitely not important
> >> for reproducible testing. It's worse than not important: it's
> >> counterproductive.
> >
> > Then maybe you also know how to force the curses libraries not to look
> > there? Again, this is not an Emacs problem.
>
> It's an Emacs problem only in that a bit of Emacs code needs to be added
> to force the curses libraries not to look there.
Does it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Sun, 03 Aug 2025 20:06:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-03 09:09, Eli Zaretskii wrote:
> I don't know what exactly happened in your case, and you never
> described all of those details. I'm telling you what Emacs is
> programmed to do.
Emacs doesn't do what you say it's programmed to do.
Here are more details. I started with Emacs master (current commit
c935b68bed174386f46dec6be525a23397a4b5f8) on Ubuntu 25.04 x86-64. I then
ran this:
./configure --with-native-compilation --prefix=/tmp/prefix
make install
mkdir test-directory
cd test-directory
HOME=/nodir PATH=/tmp/prefix/bin:/usr/bin strace -o tr emacs -nw
I then interacted with the Emacs session for a bit, doing what I
normally do. I created subshells, ran M-x hanoi (OK, this was just for
fun; I normally don't do that :-), ran M-x compile, ran version control,
etc. Everything worked except for the spurious diagnostics I mentioned
in earlier email. I eventually typed C-x C-c to exit.
When I examined 'tr' afterwards, I saw that all accesses to /nodir and
to files under /nodir failed, almost all due to ENOENT. The one
exception was a mkdir("/nodir",0777) failing due to EACCES. None of
these issues mattered, other than the spurious diagnostics which should
be easy to suppress with a new option.
> For some value of "fine". Since we don't know what happened (which
> files it tried to compile, if it tried, and where, if anywhere, it
> wrote the *.eln files), we also don't know exactly what kind of
> "working Emacs" you got as result. That it succeeded to run some
> simple commands doesn't necessarily mean it's a healthy session.
> Maybe it is, maybe it isn't.
I would not be surprised if something would break if Emacs does not
access user-specific files, just as some things already break if with -Q
or -D.
The fact remains, though, that in practice Emacs is quite useful without
accessing user-specific files. It is useful for many kinds of tests, for
people who want reproducible tests. It's even useful for ordinary work.
>> this is better for testing, as test results do not rely on the
>> contents of the user's home directory.
>
> Then your problem is solved, and we can stop this discussion
My problem is definitely not solved, because this sort of thing is a
significant hassle for people like me who want to do reproducible tests.
It's a matter of priorities. If we want Emacs to be easy to test
reproducibly, there's a real need for improvement here. If we think this
sort of testing is unimportant, then indeed we should stop this discussion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Mon, 04 Aug 2025 05:15:02 GMT)
Full text and
rfc822 format available.
Message #65 received at submit <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
>>> this is better for testing, as test results do not rely on the
>>> contents of the user's home directory.
[...]
> It's a matter of priorities. If we want Emacs to be easy to test
> reproducibly, there's a real need for improvement here. If we think
> this sort of testing is unimportant, then indeed we should stop this
> discussion.
You probably are already aware, but (if my understanding is correct) the
code that is tested with a non-existent or non-writable home directory
is byte-code interpreted, whereas with a writable home directory the
code that is run is natively compiled. So the tests will test something
subtly different than what end users will run.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Mon, 04 Aug 2025 12:24:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 3 Aug 2025 13:05:24 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-08-03 09:09, Eli Zaretskii wrote:
>
> > I don't know what exactly happened in your case, and you never
> > described all of those details. I'm telling you what Emacs is
> > programmed to do.
>
> Emacs doesn't do what you say it's programmed to do.
>
> Here are more details. I started with Emacs master (current commit
> c935b68bed174386f46dec6be525a23397a4b5f8) on Ubuntu 25.04 x86-64. I then
> ran this:
>
> ./configure --with-native-compilation --prefix=/tmp/prefix
> make install
> mkdir test-directory
> cd test-directory
> HOME=/nodir PATH=/tmp/prefix/bin:/usr/bin strace -o tr emacs -nw
>
> I then interacted with the Emacs session for a bit, doing what I
> normally do. I created subshells, ran M-x hanoi (OK, this was just for
> fun; I normally don't do that :-), ran M-x compile, ran version control,
> etc. Everything worked except for the spurious diagnostics I mentioned
> in earlier email. I eventually typed C-x C-c to exit.
>
> When I examined 'tr' afterwards, I saw that all accesses to /nodir and
> to files under /nodir failed, almost all due to ENOENT. The one
> exception was a mkdir("/nodir",0777) failing due to EACCES. None of
> these issues mattered, other than the spurious diagnostics which should
> be easy to suppress with a new option.
How does this mean that "Emacs doesn't do what you say it's programmed
to do"? I feel there's some huge misunderstanding here. Your
experiment indicated that Emacs accesses the non-existent home
directory. Naturally, all of those accesses failed, but if the
directory existed, Emacs would have used it.
Now, if setting HOME to a non-existent directory gives you what you
want, then we can stop this discussion and conclude that your use case
has a satisfactory solution. I thought, perhaps mistakenly, that you
wanted to prevent Emacs from accessing the home directory when that
directory did exist, and I therefore tried to explain why Emacs does
access it for the purposes of native-compilation needed at startup,
and what it does when it accesses the home directory. If these
accesses are to be avoided when the home directory exists, the few
relevant variables need to be changed from their defaults early enough
during startup, and if that is not enough, only code changes (which
I'm very unhappy to make) could do what you want.
I hope this clarifies the situation.
> > For some value of "fine". Since we don't know what happened (which
> > files it tried to compile, if it tried, and where, if anywhere, it
> > wrote the *.eln files), we also don't know exactly what kind of
> > "working Emacs" you got as result. That it succeeded to run some
> > simple commands doesn't necessarily mean it's a healthy session.
> > Maybe it is, maybe it isn't.
>
> I would not be surprised if something would break if Emacs does not
> access user-specific files, just as some things already break if with -Q
> or -D.
I'm talking about much more subtle issues, like the need to compile
trampolines required in some cases. Maybe what you do doesn't need
that, but in the past we had problems with disabling native
compilation when trampolines were involved, so we added a special
variable to do that safely.
> The fact remains, though, that in practice Emacs is quite useful without
> accessing user-specific files. It is useful for many kinds of tests, for
> people who want reproducible tests. It's even useful for ordinary work.
Once again, if directing HOME to a non-existent directory satisfies
your needs, that's fine by me, and we don't need to continue this
argument.
> >> this is better for testing, as test results do not rely on the
> >> contents of the user's home directory.
> >
> > Then your problem is solved, and we can stop this discussion
>
> My problem is definitely not solved, because this sort of thing is a
> significant hassle for people like me who want to do reproducible tests.
>
> It's a matter of priorities. If we want Emacs to be easy to test
> reproducibly, there's a real need for improvement here. If we think this
> sort of testing is unimportant, then indeed we should stop this discussion.
If the above means that directing HOME to a non-existent directory is
not a satisfactory solution for this case, please explain why not:
AFAIU, this does allow reproducible testing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Mon, 04 Aug 2025 13:03:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> From: Rudolf Schlatte <rudi <at> constantly.at>
> Date: Mon, 04 Aug 2025 07:13:42 +0200
>
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
> > It's a matter of priorities. If we want Emacs to be easy to test
> > reproducibly, there's a real need for improvement here. If we think
> > this sort of testing is unimportant, then indeed we should stop this
> > discussion.
>
> You probably are already aware, but (if my understanding is correct) the
> code that is tested with a non-existent or non-writable home directory
> is byte-code interpreted, whereas with a writable home directory the
> code that is run is natively compiled. So the tests will test something
> subtly different than what end users will run.
Yes, this is another downside of suppressing native compilation in a
build that's supposed to use it in production.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Mon, 04 Aug 2025 14:13:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 79124 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Aug 4, 2025, 10:00 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Rudolf Schlatte <rudi <at> constantly.at>
> > Date: Mon, 04 Aug 2025 07:13:42 +0200
> >
> > Paul Eggert <eggert <at> cs.ucla.edu> writes:
> >
> > > It's a matter of priorities. If we want Emacs to be easy to test
> > > reproducibly, there's a real need for improvement here. If we think
> > > this sort of testing is unimportant, then indeed we should stop this
> > > discussion.
> >
> > You probably are already aware, but (if my understanding is correct) the
> > code that is tested with a non-existent or non-writable home directory
> > is byte-code interpreted, whereas with a writable home directory the
> > code that is run is natively compiled. So the tests will test something
> > subtly different than what end users will run.
>
> Yes, this is another downside of suppressing native compilation in a
> build that's supposed to use it in production.
>
For reproducible testing of anything other than the support of on-demand
native compilation, the tester should build two versions of emacs. The
first --with-native-compilation=no, the second with
--with-native-compilation=aot. Then the use of byte- or native code will
be deterministic even if HOME doesn't exist.
Lynn
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Mon, 04 Aug 2025 14:17:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 79124 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
My response below is really for Paul, so I've added him back to the cc list.
On Mon, Aug 4, 2025, 10:12 AM Lynn Winebarger <owinebar <at> gmail.com> wrote:
> On Mon, Aug 4, 2025, 10:00 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Rudolf Schlatte <rudi <at> constantly.at>
>> > Date: Mon, 04 Aug 2025 07:13:42 +0200
>> >
>> > Paul Eggert <eggert <at> cs.ucla.edu> writes:
>> >
>> > > It's a matter of priorities. If we want Emacs to be easy to test
>> > > reproducibly, there's a real need for improvement here. If we think
>> > > this sort of testing is unimportant, then indeed we should stop this
>> > > discussion.
>> >
>> > You probably are already aware, but (if my understanding is correct) the
>> > code that is tested with a non-existent or non-writable home directory
>> > is byte-code interpreted, whereas with a writable home directory the
>> > code that is run is natively compiled. So the tests will test something
>> > subtly different than what end users will run.
>>
>> Yes, this is another downside of suppressing native compilation in a
>> build that's supposed to use it in production.
>>
>
> For reproducible testing of anything other than the support of on-demand
> native compilation, the tester should build two versions of emacs. The
> first --with-native-compilation=no, the second with
> --with-native-compilation=aot. Then the use of byte- or native code will
> be deterministic even if HOME doesn't exist.
>
> Lynn
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Mon, 04 Aug 2025 17:20:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-04 05:22, Eli Zaretskii wrote:
> if setting HOME to a non-existent directory gives you what you want
It doesn't, for several reasons.
* Emacs outputs spurious diagnostics. It shouldn't.
* It's a pain to communicate with other users when diagnosing. I should
be able to tell them "run emacs -QQ". But currently I have to tell them
something like "get a copy of the Emacs source, run './configure
--prefix=$HOME/prefix --with-native-compilation=aot', run 'make install'
(this may a long time; be patient), set HOME to a nonexistent directory
whose parent directory is unwritable, then run $HOME/prefix/bin/emacs -Q
except use the old HOME not the new one and make sure you are not a
superuser, and ignore the following worrisome-looking diagnostics". If
they make a single mistake (say, they run as root) the whole thing falls
apart. This is so awkward and unfriendly that I won't even bother.
* When using Emacs in this way, I can't edit my own files conveniently.
I have to use tell Emacs a name like "~eggert/foo" where I should be
able to say just "~/foo".
There are probably other reasons, these are just off the top of my head.
> I'm talking about much more subtle issues, like the need to compile
> trampolines required in some cases.
Although I don't know what those subtle issues are, I don't see what
they have to do with accessing $HOME when Emacs starts up. If Emacs
needs to read files under $HOME to compile trampolines (why?) and $HOME
is off-limits, it can access files in /tmp like other programs do.
> I thought, perhaps mistakenly, that you
> wanted to prevent Emacs from accessing the home directory when that
> directory did exist
No, I just want Emacs to skip the user-specific configuration it
normally does, so that I'm running a vanilla Emacs rather than a
tailored Emacs. This helps make tests more reproducible. I don't want to
prevent all accesses to my home directory.
The original intent of -Q was to have a convenient way to have Emacs run
independently of user-specific configuration. If -Q has strayed away
from that intent but we can't change its behavior for some backward
compatibility concern, then we should have a new short option to do the
original intent.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Mon, 04 Aug 2025 18:15:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 4 Aug 2025 10:19:12 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> > I thought, perhaps mistakenly, that you
> > wanted to prevent Emacs from accessing the home directory when that
> > directory did exist
>
> No, I just want Emacs to skip the user-specific configuration it
> normally does, so that I'm running a vanilla Emacs rather than a
> tailored Emacs.
Then accessing the eln-cache is not an issue for you, and we should
just stop wasting each other's time. As I'm quite sure I said in my
original response to your bug report. Because none of the *.eln files
are user-specific configuration, precisely like the *.elc files on the
user's machine aren't.
> The original intent of -Q was to have a convenient way to have Emacs run
> independently of user-specific configuration. If -Q has strayed away
> from that intent but we can't change its behavior for some backward
> compatibility concern, then we should have a new short option to do the
> original intent.
Then let's return to talking about the real problems: the loading of
abbrevs and perhaps the auto-save-list files (not sure that the latter
match the description of "user-specific configuration"). The rest of
the accesses to the home directory are to load and/or write *.eln
files, and have nothing to do with user configuration.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Mon, 04 Aug 2025 20:10:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-04 11:14, Eli Zaretskii wrote:
> none of the *.eln files
> are user-specific configuration
They are if the *.eln files are incorrect, which they may be for various
reasons. A reproducible test should not be disrupted merely because the
user's ~/.emacs.d/...macroexpand_0.eln is corrupt.
> precisely like the *.elc files on the
> user's machine aren't.
Are you talking about *.elc files under ~/.emacs.d? In that case, yes,
it should be just like *.eln files under ~/.emacs.d: neither kind of
file should be read on startup in a reproducible test. I observed this
issue only with *.eln files, and that is why I've been talking about
*.eln files.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Tue, 05 Aug 2025 11:20:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 4 Aug 2025 13:09:00 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-08-04 11:14, Eli Zaretskii wrote:
> > none of the *.eln files
> > are user-specific configuration
>
> They are if the *.eln files are incorrect, which they may be for various
> reasons.
Please give examples for such reasons. AFAIR, you accepted the AOT
build as a workaround for this problem, in which case I don't
understand how the *.eln files compiled from the *.el files in the
Emacs source tree are "kosher" when they are in the installation tree,
but not if they are under ~/.emacs.c/eln-cache/. I also don't
understand how are they different from *.elc files produced on the
user's machine as part of the build and installed in the installation
tree.
> A reproducible test should not be disrupted merely because the
> user's ~/.emacs.d/...macroexpand_0.eln is corrupt.
Why would it be corrupt, but the same file under /usr/lib/emacs cannot
be?
> > precisely like the *.elc files on the
> > user's machine aren't.
>
> Are you talking about *.elc files under ~/.emacs.d? In that case, yes,
> it should be just like *.eln files under ~/.emacs.d: neither kind of
> file should be read on startup in a reproducible test. I observed this
> issue only with *.eln files, and that is why I've been talking about
> *.eln files.
The directory where these files live is not important. What's
important is that they are produced from the stock Lisp sources of the
Emacs distribution, which is what you presumably want to test.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Tue, 05 Aug 2025 15:24:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-05 04:19, Eli Zaretskii wrote:
> AFAIR, you accepted the AOT
> build as a workaround for this problem,
No, I didn't. I rejected it because it's too much of a pain to expect
users to rebuild Emacs (in an especially-length process!) just to
reproduce a bug.
> I don't understand how the *.eln files compiled from the *.el files in the
> Emacs source tree are "kosher" when they are in the installation tree,
> but not if they are under ~/.emacs.c/eln-cache/.
I'm assuming that Emacs was installed correctly (if not, all bets are
off anyway). What I don't want to assume is anything in the user's home
directory, because that can make tests irreproducible.
>> A reproducible test should not be disrupted merely because the
>> user's ~/.emacs.d/...macroexpand_0.eln is corrupt.
>
> Why would it be corrupt, but the same file under /usr/lib/emacs cannot
> be?
Could be many reasons. For example, maybe they backed up their home
directory but then restored it incorrectly. Whatever the reason is, I
don't want the user's home directory to affect the test.
> The directory where these files live is not important.
It is important, because I want the tests to depend only on the
installed Emacs, not on the user's own files. That's a core part of
making tests reproducible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Tue, 05 Aug 2025 16:03:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 5 Aug 2025 08:23:22 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-08-05 04:19, Eli Zaretskii wrote:
>
> > AFAIR, you accepted the AOT
> > build as a workaround for this problem,
>
> No, I didn't. I rejected it because it's too much of a pain to expect
> users to rebuild Emacs (in an especially-length process!) just to
> reproduce a bug.
If the only problem is the pain, then you did accept it as the
workaround. The effort to produce an AOT build is not relevant to
this discussion, only the correctness of the resulting *.eln files is.
Let's please not waste time on irrelevant tangents, and focus on the
main issues.
> > I don't understand how the *.eln files compiled from the *.el files in the
> > Emacs source tree are "kosher" when they are in the installation tree,
> > but not if they are under ~/.emacs.c/eln-cache/.
>
> I'm assuming that Emacs was installed correctly (if not, all bets are
> off anyway). What I don't want to assume is anything in the user's home
> directory, because that can make tests irreproducible.
The same code which writes *.eln files in the AOT case writes them in
the user's eln-cache directory. So either both are acceptable or both
aren't.
> >> A reproducible test should not be disrupted merely because the
> >> user's ~/.emacs.d/...macroexpand_0.eln is corrupt.
> >
> > Why would it be corrupt, but the same file under /usr/lib/emacs cannot
> > be?
>
> Could be many reasons. For example, maybe they backed up their home
> directory but then restored it incorrectly. Whatever the reason is, I
> don't want the user's home directory to affect the test.
Whatever can happen with the user's home directory can also happen
with the files in the directories of the installation tree. The *.eln
files written into the user's eln-cache while compiling *.el files
from the installation tree are for all practical purposes parts of the
Emacs build, not parts of the user configuration.
> > The directory where these files live is not important.
>
> It is important, because I want the tests to depend only on the
> installed Emacs, not on the user's own files. That's a core part of
> making tests reproducible.
The files in ~/.emacs.d/eln-cache/ produced by compiling *.el files
from the installation tree are part of the installed Emacs. They just
live in a different directory.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Tue, 05 Aug 2025 16:51:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-05 08:55, Eli Zaretskii wrote:
> If the only problem is the pain, then you did accept it as the
> workaround.
This mischaracterizes what I wrote. I wrote that it "is so awkward and
unfriendly that I won't even bother". It is unreasonable to expect
bug-reporters to rebuild Emacs from scratch in a tricky procedure, and I
do not accept this as a workaround.
> Whatever can happen with the user's home directory can also happen
> with the files in the directories of the installation tree.
Also not correct in common situations where the installation files can
be trusted where the home directory cannot. In most setups, installation
files are readonly and set up by a trusted user, whereas the home
directory is not.
> The *.eln
> files written into the user's eln-cache while compiling *.el files
> from the installation tree are for all practical purposes parts of the
> Emacs build, not parts of the user configuration.
Not if the files were corrupted after being written. And there are other
reasons they might not be the same in practice.
> The files in ~/.emacs.d/eln-cache/ produced by compiling *.el files
> from the installation tree are part of the installed Emacs.
But that assumes that those files' contents are correct. An important
part of testing is to check assumptions like that. Testing should not
make unnecessary assumptions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Tue, 05 Aug 2025 17:53:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 79124 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 2025-08-05 08:55, Eli Zaretskii wrote:
>
>> If the only problem is the pain, then you did accept it as the
>> workaround.
>
> This mischaracterizes what I wrote. I wrote that it "is so awkward and
> unfriendly that I won't even bother". It is unreasonable to expect
> bug-reporters to rebuild Emacs from scratch in a tricky procedure, and
> I do not accept this as a workaround.
>
>> Whatever can happen with the user's home directory can also happen
>> with the files in the directories of the installation tree.
>
> Also not correct in common situations where the installation files can
> be trusted where the home directory cannot. In most setups,
> installation files are readonly and set up by a trusted user, whereas
> the home directory is not.
>
>> The *.eln
>> files written into the user's eln-cache while compiling *.el files
>> from the installation tree are for all practical purposes parts of the
>> Emacs build, not parts of the user configuration.
>
> Not if the files were corrupted after being written. And there are
> other reasons they might not be the same in practice.
>
>> The files in ~/.emacs.d/eln-cache/ produced by compiling *.el files
>> from the installation tree are part of the installed Emacs.
>
> But that assumes that those files' contents are correct. An important
> part of testing is to check assumptions like that. Testing should not
> make unnecessary assumptions.
FWIW, I agree with this. But I don't know why something like this would
not work:
emacs -Q --init-directory=$(mktemp -d)
Does the eln cache does not honor the init directory?
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Tue, 05 Aug 2025 19:21:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 5 Aug 2025 09:50:42 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-08-05 08:55, Eli Zaretskii wrote:
>
> > If the only problem is the pain, then you did accept it as the
> > workaround.
>
> This mischaracterizes what I wrote. I wrote that it "is so awkward and
> unfriendly that I won't even bother". It is unreasonable to expect
> bug-reporters to rebuild Emacs from scratch in a tricky procedure, and I
> do not accept this as a workaround.
Once again, I didn't say they should. I said that if the result of
AOT build would be acceptable for this kind of testing, then so should
be the results of JIT compilation of the same Lisp files into the same
*.eln files, just because they are loaded from a different directory.
> > Whatever can happen with the user's home directory can also happen
> > with the files in the directories of the installation tree.
>
> Also not correct in common situations where the installation files can
> be trusted where the home directory cannot.
These files are not "home directory", they just live there. Emacs
compiles them exactly as it does during an AOT build, it just does it
in JIT manner, and it writes them under the home directory. That's
all the difference between those two.
> In most setups, installation files are readonly and set up by a
> trusted user, whereas the home directory is not.
We are talking about users, such as yourself, who run such tests.
Those users are most probably building and installing their own Emacs.
So they _are_ that trusted user, in both cases.
> > The *.eln
> > files written into the user's eln-cache while compiling *.el files
> > from the installation tree are for all practical purposes parts of the
> > Emacs build, not parts of the user configuration.
>
> Not if the files were corrupted after being written.
The files can be corrupted in any place, not only in the home
directory. Why do you trust the installed files to not be corrupt?
> > The files in ~/.emacs.d/eln-cache/ produced by compiling *.el files
> > from the installation tree are part of the installed Emacs.
>
> But that assumes that those files' contents are correct.
Their contents are as correct as of the byte-compiled and
natively-compiled files in the installation tree. They were produced
from the same sources, likely by the same compiler.
> An important part of testing is to check assumptions like
> that. Testing should not make unnecessary assumptions.
There are no assumptions here that are not present when you test the
files from the installation tree.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Tue, 05 Aug 2025 20:49:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-05 12:19, Eli Zaretskii wrote:
> These files are not "home directory", they just live there.
Because they live in the home directory, they're subject to all the
problems that any home-directory files can have, and those are problems
that -Q (or -QQ if you prefer) are supposed to work around. It doesn't
matter whether the files were last modified by Emacs or by some other
program.
>> In most setups, installation files are readonly and set up by a
>> trusted user, whereas the home directory is not.
>
> We are talking about users, such as yourself, who run such tests.
> Those users are most probably building and installing their own Emacs.
No, I respond to bug reports (mostly not on this forum) from people who
typically are not building and installing their own Emacs. They're
running an Emacs that the system made available to them.
> The files can be corrupted in any place, not only in the home
> directory. Why do you trust the installed files to not be corrupt?
Because the installed files are read-only, the user can't modify them,
and so they are as trustworthy as the rest of the distro. This is
standard practice on GNU/Linux and similar systems.
I continue to be puzzled by the idea that -Q should read from
$HOME/.emacs.d. If there's a reason for that behavior, we should add a
flag -QQ that avoids reading from $HOME during startup. This would be a
real win for a common use case, and it wouldn't hurt other uses.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Tue, 05 Aug 2025 20:49:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-05 10:52, Manuel Giraud wrote:
> I don't know why something like this would
> not work:
>
> emacs -Q --init-directory=$(mktemp -d)
That leaves behind a directory in /tmp. Actually, it leaves two of them
behind, one for a different reason; libgccjit creates it. Although these
are not fatal objections, they're messes that we're better off without.
Testing should be simple, not complicated.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 11:17:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 79124 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 2025-08-05 10:52, Manuel Giraud wrote:
>> I don't know why something like this would
>> not work:
>> emacs -Q --init-directory=$(mktemp -d)
>
> That leaves behind a directory in /tmp.
Yes I know. My idea was to first identify is this is sufficient to
create an isolated environment for Emacs.
> Actually, it leaves two of them behind, one for a different reason;
> libgccjit creates it.
Which directory does libgccjit create?
> Although these are not fatal objections, they're messes that we're
> better off without. Testing should be simple, not complicated.
Yes of course. The second part of my idea is that maybe -Q could be a
shortcut for "-q --no-site-file --no-splash
--init-directory=$TMPDIR_SOMEWHERE_THAT_WOULD_BE_DELETED_WHEN_QUITTING"
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 12:36:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 5 Aug 2025 13:48:28 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-08-05 12:19, Eli Zaretskii wrote:
>
> > These files are not "home directory", they just live there.
>
> Because they live in the home directory, they're subject to all the
> problems that any home-directory files can have, and those are problems
> that -Q (or -QQ if you prefer) are supposed to work around. It doesn't
> matter whether the files were last modified by Emacs or by some other
> program.
>
> >> In most setups, installation files are readonly and set up by a
> >> trusted user, whereas the home directory is not.
> >
> > We are talking about users, such as yourself, who run such tests.
> > Those users are most probably building and installing their own Emacs.
>
> No, I respond to bug reports (mostly not on this forum) from people who
> typically are not building and installing their own Emacs. They're
> running an Emacs that the system made available to them.
>
> > The files can be corrupted in any place, not only in the home
> > directory. Why do you trust the installed files to not be corrupt?
>
> Because the installed files are read-only, the user can't modify them,
> and so they are as trustworthy as the rest of the distro. This is
> standard practice on GNU/Linux and similar systems.
If you still insist on this, then we will have to agree to disagree.
The solution we use in the test suite is to set HOME to a non-existent
directory, so that's what I can suggest in your case.
> I continue to be puzzled by the idea that -Q should read from
> $HOME/.emacs.d.
The reason is our decision that JIT-compiled Lisp files are written
under the user home directory (and I don't think that decision was
wrong). The other part of the puzzle is that it is not always
possible to predict in advance what Lisp files will be automatically
loaded at startup because they are needed by the startup code, so they
couldn't all be natively-compiled in advance.
> If there's a reason for that behavior, we should add a
> flag -QQ that avoids reading from $HOME during startup. This would be a
> real win for a common use case, and it wouldn't hurt other uses.
As I explained, I'm not interested in adding yet another way of
avoiding native-compilation, because what we have is versatile and
complex enough.
Sorry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 13:09:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rpluim <at> gmail.com, 79124 <at> debbugs.gnu.org,
> rms <at> gnu.org
> Date: Wed, 06 Aug 2025 13:16:27 +0200
>
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
> > Although these are not fatal objections, they're messes that we're
> > better off without. Testing should be simple, not complicated.
>
> Yes of course. The second part of my idea is that maybe -Q could be a
> shortcut for "-q --no-site-file --no-splash
> --init-directory=$TMPDIR_SOMEWHERE_THAT_WOULD_BE_DELETED_WHEN_QUITTING"
That's an incompatible change, so we cannot easily make -Q do that.
No one said that -Q makes the user's home directory inaccessible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 13:50:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-06 05:34, Eli Zaretskii wrote:
> The other part of the puzzle is that it is not always
> possible to predict in advance what Lisp files will be automatically
> loaded at startup because they are needed by the startup code, so they
> couldn't all be natively-compiled in advance.
That part of the puzzle does not apply, since -Q means "don't run
startup code".
> I'm not interested in adding yet another way of
> avoiding native-compilation
But I'm not asking for another way to avoid native compilation. Native
compilation is fine. Just don't trust what's already in .emacs.d, that's
all.
> The solution we use in the test suite is to set HOME to a non-existent
> directory, so that's what I can suggest in your case.
That suggestion is inadequate, as it leads to bogus diagnostics and/or
detritus after the test. However you are unwilling to change your mind
even to add a simple flag, and you are a maintainer whereas I am not.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 13:52:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-06 04:16, Manuel Giraud wrote:
> Which directory does libgccjit create?
/tmp/libgccjit-6kC11F in one test run. (Which belies the misguided
notion that Emacs must do this stuff in its home directory.)
> Yes of course. The second part of my idea is that maybe -Q could be a
> shortcut for "-q --no-site-file --no-splash
> --init-directory=$TMPDIR_SOMEWHERE_THAT_WOULD_BE_DELETED_WHEN_QUITTING"
Eli already rejected a solution along those lines, unfortunately.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 14:57:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 6 Aug 2025 06:49:45 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-08-06 05:34, Eli Zaretskii wrote:
>
> > The other part of the puzzle is that it is not always
> > possible to predict in advance what Lisp files will be automatically
> > loaded at startup because they are needed by the startup code, so they
> > couldn't all be natively-compiled in advance.
>
> That part of the puzzle does not apply, since -Q means "don't run
> startup code".
No, it doesn't. startup.el's code is run in "emacs -Q" as well
(although some parts of it, like loading the user init file, are
omitted).
> > I'm not interested in adding yet another way of
> > avoiding native-compilation
>
> But I'm not asking for another way to avoid native compilation. Native
> compilation is fine. Just don't trust what's already in .emacs.d, that's
> all.
The way JIT native compilation works, it writes the *.eln files under
the user home directory, and looks there for *.eln files that were
already compiled. So yes, you are asking to either avoid this or
significantly change how it works.
> > The solution we use in the test suite is to set HOME to a non-existent
> > directory, so that's what I can suggest in your case.
>
> That suggestion is inadequate, as it leads to bogus diagnostics and/or
> detritus after the test. However you are unwilling to change your mind
> even to add a simple flag, and you are a maintainer whereas I am not.
My problem is not with adding a flag, it's with modifying code to
support that flag.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 14:59:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 6 Aug 2025 06:50:55 -0700
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rpluim <at> gmail.com, 79124 <at> debbugs.gnu.org,
> rms <at> gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-08-06 04:16, Manuel Giraud wrote:
>
> > Which directory does libgccjit create?
>
> /tmp/libgccjit-6kC11F in one test run. (Which belies the misguided
> notion that Emacs must do this stuff in its home directory.)
Are you sure this directory is created by Emacs, not by libgccjit
itself?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 15:38:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-06 07:55, Eli Zaretskii wrote:
>>> The other part of the puzzle is that it is not always
>>> possible to predict in advance what Lisp files will be automatically
>>> loaded at startup because they are needed by the startup code, so they
>>> couldn't all be natively-compiled in advance.
>>
>> That part of the puzzle does not apply, since -Q means "don't run
>> startup code".
>
> No, it doesn't. startup.el's code is run in "emacs -Q" as well
> (although some parts of it, like loading the user init file, are
> omitted).
I meant the user startup code. But I don't see why the other part of the
puzzle applies for the non-user-specific part of startup.el, as that
stuff ought to be precompiled, not taken from the user's home directory.
>> But I'm not asking for another way to avoid native compilation. Native
>> compilation is fine. Just don't trust what's already in .emacs.d, that's
>> all.
>
> The way JIT native compilation works, it writes the *.eln files under
> the user home directory, and looks there for *.eln files that were
> already compiled. So yes, you are asking to either avoid this or
> significantly change how it works.
? It's not much of a change to put in /tmp where it belongs. After all,
Emacs puts this stuff in /tmp no matter what we do with $HOME, because
libgccjit ignores $HOME and uses /tmp directly.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 16:23:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 6 Aug 2025 08:37:42 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-08-06 07:55, Eli Zaretskii wrote:
> >>> The other part of the puzzle is that it is not always
> >>> possible to predict in advance what Lisp files will be automatically
> >>> loaded at startup because they are needed by the startup code, so they
> >>> couldn't all be natively-compiled in advance.
> >>
> >> That part of the puzzle does not apply, since -Q means "don't run
> >> startup code".
> >
> > No, it doesn't. startup.el's code is run in "emacs -Q" as well
> > (although some parts of it, like loading the user init file, are
> > omitted).
>
> I meant the user startup code. But I don't see why the other part of the
> puzzle applies for the non-user-specific part of startup.el, as that
> stuff ought to be precompiled, not taken from the user's home directory.
Because startup.el can load Lisp packages that are not preloaded. The
terminal-specific library from lisp/term/ and warnings.el are two that
come to mind, but I won't be surprised that there are more.
> >> But I'm not asking for another way to avoid native compilation. Native
> >> compilation is fine. Just don't trust what's already in .emacs.d, that's
> >> all.
> >
> > The way JIT native compilation works, it writes the *.eln files under
> > the user home directory, and looks there for *.eln files that were
> > already compiled. So yes, you are asking to either avoid this or
> > significantly change how it works.
>
> ? It's not much of a change to put in /tmp where it belongs. After all,
> Emacs puts this stuff in /tmp no matter what we do with $HOME, because
> libgccjit ignores $HOME and uses /tmp directly.
I fail to see the difference between trusting files in /tmp and
trusting files in ~/.emacs.d/eln-cache. It sounds to me like some
dogmatic notion which has no real basis. Why should we make changes
in what is already super-complicated code on such shaky grounds? No,
thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 16:30:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-06 09:22, Eli Zaretskii wrote:
> Because startup.el can load Lisp packages that are not preloaded. The
> terminal-specific library from lisp/term/ and warnings.el are two that
> come to mind, but I won't be surprised that there are more.
That's fine; these files can be compiled as needed. Emacs simply need
not consult the user home directory to see whether they have already
been compiled by a previous Emacs execution.
> I fail to see the difference between trusting files in /tmp and
> trusting files in ~/.emacs.d/eln-cache.
Those files in /tmp are all created by the current Emacs execution, and
can be trusted for that reason. The files that were already in
~/.emacs.d/eln-cache are not, and they might have been corrupted for
various reasons since they were created by a previous execution. That's
an important difference.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 19:01:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 6 Aug 2025 09:29:44 -0700
> Cc: rpluim <at> gmail.com, rms <at> gnu.org, 79124 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2025-08-06 09:22, Eli Zaretskii wrote:
>
> > Because startup.el can load Lisp packages that are not preloaded. The
> > terminal-specific library from lisp/term/ and warnings.el are two that
> > come to mind, but I won't be surprised that there are more.
>
> That's fine; these files can be compiled as needed. Emacs simply need
> not consult the user home directory to see whether they have already
> been compiled by a previous Emacs execution.
It currently can't, and I'm unwilling to complicate what we have so it
will be able to, sorry.
> > I fail to see the difference between trusting files in /tmp and
> > trusting files in ~/.emacs.d/eln-cache.
>
> Those files in /tmp are all created by the current Emacs execution, and
> can be trusted for that reason. The files that were already in
> ~/.emacs.d/eln-cache are not, and they might have been corrupted for
> various reasons since they were created by a previous execution. That's
> an important difference.
I fail to see the important difference: who said the corruption, such
as it is, could only happen some time ago, but not immediately as the
files are created?
But this discussion leads nowhere, since we both have opinions that
cannot be changed by these arguments. So let's leave it at that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79124; Package
emacs.
(Wed, 06 Aug 2025 19:27:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 79124 <at> debbugs.gnu.org (full text, mbox):
On 2025-08-06 11:59, Eli Zaretskii wrote:
> I fail to see the important difference: who said the corruption, such
> as it is, could only happen some time ago, but not immediately as the
> files are created?
It's of course theoretically possible, just as many other things are
theoretically possible. But practically speaking, it's far, far more
likely for a user to screw up their home directory over a period of
several hours or days or more, using any of many common techniques
(e.g., backups or restores going wrong). None of that is at all likely
with /tmp files created a few milliseconds ago.
This is a practical issue, not a theoretical one. It's better to not
ignore practical issues merely because of concerns about issues that are
problems only in theory.
However, as I mentioned you are a maintainer and I am not, and I suppose
Emacs users will have to live with your opinion, right or wrong.
This bug report was last modified 2 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.