GNU bug report logs - #79124
emacs -Q doesn't give me a clean slate

Previous Next

Full log

Message #53 received at 79124 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rpluim <at> gmail.com, 79124 <at> debbugs.gnu.org, rms <at> gnu.org
Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate
Date: Sat, 02 Aug 2025 22:28:51 +0300

> 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.

Previous Next

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