GNU bug report logs -
#79124
emacs -Q doesn't give me a clean slate
Previous Next
Full log
Message #62 received at 79124 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.