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: Mon, 04 Aug 2025 15:22:55 +0300

> Date: Sun, 3 Aug 2025 13:05:24 -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-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.

How does this mean that "Emacs doesn't do what you say it's programmed
to do"?  I feel there's some huge misunderstanding here.  Your
experiment indicated that Emacs accesses the non-existent home
directory.  Naturally, all of those accesses failed, but if the
directory existed, Emacs would have used it.

Now, if setting HOME to a non-existent directory gives you what you
want, then we can stop this discussion and conclude that your use case
has a satisfactory solution.  I thought, perhaps mistakenly, that you
wanted to prevent Emacs from accessing the home directory when that
directory did exist, and I therefore tried to explain why Emacs does
access it for the purposes of native-compilation needed at startup,
and what it does when it accesses the home directory.  If these
accesses are to be avoided when the home directory exists, the few
relevant variables need to be changed from their defaults early enough
during startup, and if that is not enough, only code changes (which
I'm very unhappy to make) could do what you want.

I hope this clarifies the situation.

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

I'm talking about much more subtle issues, like the need to compile
trampolines required in some cases.  Maybe what you do doesn't need
that, but in the past we had problems with disabling native
compilation when trampolines were involved, so we added a special
variable to do that safely.

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

Once again, if directing HOME to a non-existent directory satisfies
your needs, that's fine by me, and we don't need to continue this
argument.

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

If the above means that directing HOME to a non-existent directory is
not a satisfactory solution for this case, please explain why not:
AFAIU, this does allow reproducible testing.

Previous Next

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