Subject: bug#78304: 31.0.50; Support --early-eval on the command line

From: Lynn Winebarger <[email-masked]>
Date: Thu, 15 May 2025 13:33:19 -0400

On Thu, May 15, 2025 at 1:06 PM Spencer Baugh via Bug reports for GNU
Emacs, the Swiss army knife of text editors <[email-masked]>
wrote:
>
> Eli Zaretskii <[email-masked]> writes:
>
> >> From: Spencer Baugh <[email-masked]>
> >> Cc: [email-masked]
> >> Date: Thu, 15 May 2025 12:19:16 -0400
> >>
> >> Eli Zaretskii <[email-masked]> writes:
> >>
> >> >> > Why do you want to do that under -q?
> >> >>
> >> >> Two concrete use cases:
> >> >>
> >> >> - Since load-path-filter-function speeds up all subsequent loads, it
> >> >>   needs to be set at early-init.el time to have maximum effect, but I
> >> >>   want to also be able to use it and test it with emacs -q.
> >> >
> >> > 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.
>
> >> >> - 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.
>
> (This all also holds without -q)

You could always write a "site-init.el" or "site-load.el" at build
time that will loaded by "loadup.el" during the dump process.  You can
add a function to 'after-pdump-load-hook, which will be run by the C
runtime immediately after the dump file is loaded, before any of the
normal startup code (from startup.el) is run, even before the top
level recursive-edit is called.  You can redefine the "top-level"
function to do whatever you want for your site.

Lynn