GNU bug report logs - #78304
31.0.50; Support --early-eval on the command line

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Wed, 7 May 2025 21:35:02 UTC

Severity: normal

Found in version 31.0.50

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 78304 <at> debbugs.gnu.org
Subject: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Fri, 16 May 2025 09:10:50 +0300
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 78304 <at> debbugs.gnu.org
> Date: Thu, 15 May 2025 13:05:14 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > Since early-init.el is not supposed to load anything, only set up some
> >> > variables, I don't understand why you insist on doing this in
> >> > early-init.  The site-start file is loaded right after early-init.el,
> >> > so if you set that up at the very beginning of site-start file, it
> >> > will have the same effect.
> >> 
> >> That is not the case: Many things happen, including loading of files,
> >> between site-start and early-init.  Package initialization and initial
> >> frame setup, for example.
> >
> > And why is that important in your cases, again?  You never said
> > anything about packages and frame initialization.
> 
> Because load-path-filter-function affects loading of files, so it
> affects anything that causes loading of files, which includes packages
> and frame initialization.
> 
> Those things happen before site-start.
> 
> Therefore, for load-path-filter-function to affect those things (which
> is desirable, it's a performance optimization that will speed them up)
> it needs to be set before those things.

This problem disappears if you don't use -q, so it sounds like your
desire to use -q is the culprit.  I don't see why do you need -q, and
you still haven't explained the reasons for that.

> >> >> - Context: I'm developing some scripts to run Emacs in a simple
> >> >>   reduced-functionality mode, which provide access to just one buffer
> >> >>   running in a specific major mode, with the goal of making Emacs
> >> >>   features accessible to users who don't currently use Emacs.  For
> >> >>   example, vc-dir is generally useful, so a script to open Emacs running
> >> >>   vc-dir on its own.  (These scripts are similar to things like
> >> >>   https://github.com/maio/smagit and
> >> >>   https://github.com/alphapapa/magit.sh )
> >> >> 
> >> >>   These scripts run with -q, but I need to be able to configure things
> >> >>   about the initial frame, which can only be done with early-init.el.
> >> >
> >> > Same question here: why cannot this be done in site-start file?  IMO,
> >> > it is even cleaner, because it doesn't require each user to do the
> >> > same in their early-init files; instead, you will do that only once
> >> > for all of them.
> >> 
> >> Because initial frame setup happens before site-start is loaded.
> >
> > So now please explain why that is an issue in -q invocations.
> 
> When invoking Emacs with -q:
> 
> - Initial frame setup happens before site-start is loaded.
> - Therefore, initial frame setup cannot be customized in site-start.
> - Therefore, I cannot do the things I want to do with site-start.

What frame-setup customizations are we talking about?

> (This all also holds without -q)

Without -q, early-init.el _is_ loaded, so whatever you need to do can
be done there.

So, once again, please explain why you insist on using -q.




This bug report was last modified 30 days ago.

Previous Next


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