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

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Wed, 30 Jul 2025 00:00:02 UTC

Severity: normal

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: Thu, 31 Jul 2025 18:53:09 +0300
> 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.




This bug report was last modified 4 days ago.

Previous Next


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