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

Previous Next

Full log

View this message in rfc822 format

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: bug#79124: emacs -Q doesn't give me a clean slate
Date: Wed, 06 Aug 2025 19:22:26 +0300

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

Previous Next

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