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

From: Spencer Baugh <[email-masked]>
Date: Thu, 15 May 2025 15:08:34 -0400

Lynn Winebarger <[email-masked]> writes:
> 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.

That's true enough, but this is not about my site - the only reason site
files came up is because Eli mentioned them.  Both of the use cases I
mentioned (setting load-path-filter-function, using a script to run a
reduced-functionality Emacs) should work for users anywhere without
requring them to compile their own Emacs.