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 #56 received at 79124 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Sun, 3 Aug 2025 08:52:36 -0700
On 2025-08-02 12:28, Eli Zaretskii wrote:
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>> -nw or not, everything
>> works for me despite there being no eln cache. Nothing goes wrong. Emacs
>> works fine other than spurious diagnostics that a new flag would
>> suppress. So I'm still puzzled as to why the eln cache is essential for
>> Emacs to operate.
> 
> Because Emacs writes there the *.eln files it produces at startup.

But Emacs doesn't do that. Under the scenario I gave, Emacs does not 
write *.eln files as there's no place to write them: the cache directory 
does not exist and cannot be created.

And Emacs still works fine. And this is better for testing, as test 
results do not rely on the contents of the user's home directory.


> I don't understand what you are saying here.  The trust thing is for
> security, so why would it be applicable to *.eln files?

I'm a bit fuzzy on exactly when Emacs refuses to load an *.eln file, but 
whatever reason Emacs doesn't do it (security, API incompatibility, 
wrong architecture, out of date with respect to source, ...) we can add 
the new -QQ option as another reason not to do it. This should not be a 
drastic change.


>>> I don't know what could be in ~/.terminfo, so I don't understand the
>>> implications of that.
>>
>> I know what could be in ~/.terminfo, and it's definitely not important
>> for reproducible testing. It's worse than not important: it's
>> counterproductive.
> 
> Then maybe you also know how to force the curses libraries not to look
> there?  Again, this is not an Emacs problem.

It's an Emacs problem only in that a bit of Emacs code needs to be added 
to force the curses libraries not to look there.




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.