Subject: Re: bug#79124: emacs -Q doesn't give me a clean slate

From: Eli Zaretskii <[email-masked]>
Date: Thu, 31 Jul 2025 08:45:54 +0300

> Date: Wed, 30 Jul 2025 22:05:31 -0700
> Cc: [email-masked], [email-masked], [email-masked]
> From: Paul Eggert <[email-masked]>
> 
> 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?