GNU bug report logs -
#79124
emacs -Q doesn't give me a clean slate
Previous Next
Full log
Message #89 received at 79124 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 4 Aug 2025 13:09:00 -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-04 11:14, Eli Zaretskii wrote:
> > none of the *.eln files
> > are user-specific configuration
>
> They are if the *.eln files are incorrect, which they may be for various
> reasons.
Please give examples for such reasons. AFAIR, you accepted the AOT
build as a workaround for this problem, in which case I don't
understand how the *.eln files compiled from the *.el files in the
Emacs source tree are "kosher" when they are in the installation tree,
but not if they are under ~/.emacs.c/eln-cache/. I also don't
understand how are they different from *.elc files produced on the
user's machine as part of the build and installed in the installation
tree.
> A reproducible test should not be disrupted merely because the
> user's ~/.emacs.d/...macroexpand_0.eln is corrupt.
Why would it be corrupt, but the same file under /usr/lib/emacs cannot
be?
> > precisely like the *.elc files on the
> > user's machine aren't.
>
> Are you talking about *.elc files under ~/.emacs.d? In that case, yes,
> it should be just like *.eln files under ~/.emacs.d: neither kind of
> file should be read on startup in a reproducible test. I observed this
> issue only with *.eln files, and that is why I've been talking about
> *.eln files.
The directory where these files live is not important. What's
important is that they are produced from the stock Lisp sources of the
Emacs distribution, which is what you presumably want to test.
This bug report was last modified 5 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.