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

Previous Next

Full log

View this message in rfc822 format

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: bug#79124: emacs -Q doesn't give me a clean slate
Date: Sun, 03 Aug 2025 19:09:38 +0300

> Date: Sun, 3 Aug 2025 08:52:36 -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-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.

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.

> And Emacs still works fine.

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.

> And 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, which
from my POV goes nowhere useful?  I thought you were asking for some
code changes?  If you are happy with what we have now, I'm fine with
that.  Otherwise, I don't think I understand what are you trying to
say.

> > 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.

Sorry, I'm not interested.  We already have enough knobs to disable
native compilation (they are described in the manual), and I see no
reason to add more.

> >>> 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.

Does it?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.