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

From: Paul Eggert <[email-masked]>
Date: Sun, 3 Aug 2025 13:05:24 -0700

On 2025-08-03 09:09, Eli Zaretskii wrote:

> I don't know what exactly happened in your case, and you never
> described all of those details.  I'm telling you what Emacs is
> programmed to do.

Emacs doesn't do what you say it's programmed to do.

Here are more details. I started with Emacs master (current commit 
c935b68bed174386f46dec6be525a23397a4b5f8) on Ubuntu 25.04 x86-64. I then 
ran this:

./configure --with-native-compilation --prefix=/tmp/prefix
make install
mkdir test-directory
cd test-directory
HOME=/nodir PATH=/tmp/prefix/bin:/usr/bin strace -o tr emacs -nw

I then interacted with the Emacs session for a bit, doing what I 
normally do. I created subshells, ran M-x hanoi (OK, this was just for 
fun; I normally don't do that :-), ran M-x compile, ran version control, 
etc. Everything worked except for the spurious diagnostics I mentioned 
in earlier email. I eventually typed C-x C-c to exit.

When I examined 'tr' afterwards, I saw that all accesses to /nodir and 
to files under /nodir failed, almost all due to ENOENT. The one 
exception was a mkdir("/nodir",0777) failing due to EACCES. None of 
these issues mattered, other than the spurious diagnostics which should 
be easy to suppress with a new option.

> For some value of "fine".  Since we don't know what happened (which
> files it tried to compile, if it tried, and where, if anywhere, it
> wrote the *.eln files), we also don't know exactly what kind of
> "working Emacs" you got as result.  That it succeeded to run some
> simple commands doesn't necessarily mean it's a healthy session.
> Maybe it is, maybe it isn't.

I would not be surprised if something would break if Emacs does not 
access user-specific files, just as some things already break if with -Q 
or -D.

The fact remains, though, that in practice Emacs is quite useful without 
accessing user-specific files. It is useful for many kinds of tests, for 
people who want reproducible tests. It's even useful for ordinary work.

>> this is better for testing, as test results do not rely on the
>> contents of the user's home directory.
> 
> Then your problem is solved, and we can stop this discussion

My problem is definitely not solved, because this sort of thing is a 
significant hassle for people like me who want to do reproducible tests.

It's a matter of priorities. If we want Emacs to be easy to test 
reproducibly, there's a real need for improvement here. If we think this 
sort of testing is unimportant, then indeed we should stop this discussion.