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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 06 Aug 2025 15:34:56 +0300

> Date: Tue, 5 Aug 2025 13:48:28 -0700
> Cc: [email-masked], [email-masked], [email-masked]
> From: Paul Eggert <[email-masked]>
> 
> On 2025-08-05 12:19, Eli Zaretskii wrote:
> 
> > These files are not "home directory", they just live there.
> 
> Because they live in the home directory, they're subject to all the 
> problems that any home-directory files can have, and those are problems 
> that -Q (or -QQ if you prefer) are supposed to work around. It doesn't 
> matter whether the files were last modified by Emacs or by some other 
> program.
> 
> >> In most setups, installation files are readonly and set up by a
> >> trusted user, whereas the home directory is not.
> > 
> > We are talking about users, such as yourself, who run such tests.
> > Those users are most probably building and installing their own Emacs.
> 
> No, I respond to bug reports (mostly not on this forum) from people who 
> typically are not building and installing their own Emacs. They're 
> running an Emacs that the system made available to them.
> 
> > The files can be corrupted in any place, not only in the home
> > directory.  Why do you trust the installed files to not be corrupt?
> 
> Because the installed files are read-only, the user can't modify them, 
> and so they are as trustworthy as the rest of the distro. This is 
> standard practice on GNU/Linux and similar systems.

If you still insist on this, then we will have to agree to disagree.
The solution we use in the test suite is to set HOME to a non-existent
directory, so that's what I can suggest in your case.

> I continue to be puzzled by the idea that -Q should read from 
> $HOME/.emacs.d.

The reason is our decision that JIT-compiled Lisp files are written
under the user home directory (and I don't think that decision was
wrong).  The other part of the puzzle is that it is not always
possible to predict in advance what Lisp files will be automatically
loaded at startup because they are needed by the startup code, so they
couldn't all be natively-compiled in advance.

> If there's a reason for that behavior, we should add a 
> flag -QQ that avoids reading from $HOME during startup. This would be a 
> real win for a common use case, and it wouldn't hurt other uses.

As I explained, I'm not interested in adding yet another way of
avoiding native-compilation, because what we have is versatile and
complex enough.

Sorry.