GNU bug report logs -
#79124
emacs -Q doesn't give me a clean slate
Previous Next
Full log
View this message in rfc822 format
> 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.
This bug report was last modified 5 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.