GNU bug report logs - #79124
emacs -Q doesn't give me a clean slate

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Wed, 30 Jul 2025 00:00:02 UTC

Severity: normal

Full log


Message #104 received at 79124 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#79124: emacs -Q doesn't give me a clean slate
Date: Tue, 05 Aug 2025 22:19:45 +0300
> Date: Tue, 5 Aug 2025 09:50:42 -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-05 08:55, Eli Zaretskii wrote:
> 
> > If the only problem is the pain, then you did accept it as the
> > workaround.
> 
> This mischaracterizes what I wrote. I wrote that it "is so awkward and 
> unfriendly that I won't even bother". It is unreasonable to expect 
> bug-reporters to rebuild Emacs from scratch in a tricky procedure, and I 
> do not accept this as a workaround.

Once again, I didn't say they should.  I said that if the result of
AOT build would be acceptable for this kind of testing, then so should
be the results of JIT compilation of the same Lisp files into the same
*.eln files, just because they are loaded from a different directory.

> > Whatever can happen with the user's home directory can also happen
> > with the files in the directories of the installation tree.
> 
> Also not correct in common situations where the installation files can 
> be trusted where the home directory cannot.

These files are not "home directory", they just live there.  Emacs
compiles them exactly as it does during an AOT build, it just does it
in JIT manner, and it writes them under the home directory.  That's
all the difference between those two.

> 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.
So they _are_ that trusted user, in both cases.

> > The *.eln
> > files written into the user's eln-cache while compiling *.el files
> > from the installation tree are for all practical purposes parts of the
> > Emacs build, not parts of the user configuration.
> 
> Not if the files were corrupted after being written.

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?

> > The files in ~/.emacs.d/eln-cache/ produced by compiling *.el files
> > from the installation tree are part of the installed Emacs.
> 
> But that assumes that those files' contents are correct.

Their contents are as correct as of the byte-compiled and
natively-compiled files in the installation tree.  They were produced
from the same sources, likely by the same compiler.

> An important part of testing is to check assumptions like
> that. Testing should not make unnecessary assumptions.

There are no assumptions here that are not present when you test the
files from the installation tree.




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.