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

From: Paul Eggert <[email-masked]>
Date: Thu, 31 Jul 2025 07:43:09 -0700

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?

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

Presumably a new -QQ option would disable that part of the startup.

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