Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Wed, 14 May 2025 13:07:16 -0400
>> Cc: 78304@debbugs.gnu.org
>>
>> On Wed, May 14, 2025, 12:26 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>  > From: Spencer Baugh <sbaugh@janestreet.com>
>>  > Date: Wed, 14 May 2025 11:36:40 -0400
>>  > Cc: 78304@debbugs.gnu.org
>>  >
>>  > On Wed, May 14, 2025, 7:29 AM Eli Zaretskii <eliz@gnu.org> wrote:
>>  >
>>  >  > From: Spencer Baugh <sbaugh@janestreet.com>
>>  >  > Cc: 78304@debbugs.gnu.org
>>  >  > Date: Tue, 13 May 2025 14:10:24 -0400
>>  >  >
>>  >  > Eli Zaretskii <eliz@gnu.org> writes:
>>  >  >
>>  >  > > Why cannot you do whatever you need in the site-init file?
>>  >  >
>>  >  > By that I assume you mean site-start.el, since AFAIK site-init.el is not
>>  >  > loaded at runtime, only at dump time.
>>  >  >
>>  >  > As (info "(elisp) Startup Summary") describes, site-start.el is loaded
>>  >  > after package-activate-all is called and the initial frame is set up.
>>  >  > It is therefore loaded too late to configure these things.
>>  >
>>  >  That's easy to overcome: set package-enable-at-startup to a nil value
>>  >  in early-init.el, then call package-activate-all in site-start file.
>>  >
>>  >  Does this solve the problem?
>>  >
>>  > No, because as I said above, there's no way to combine this solution with -q.
>>
>>  I don't understand why.  The -q switch doesn't disable loading
>>  site-start file.
>>
>> It disables loading early-init.el.
>
> And why is that a problem in this case?
>
> IOW, you seem to be describing several different situations, but each
> one of them might need a slightly different solution.  E.g., you never
> explained why you want to do whatever you need to do in "emacs -q".
>
> Given all these undisclosed details and rationales, it is hard to have
> a useful and efficient discussion.  I almost feel like the rules of
> the game change with each new message, and no matter what I suggest,
> it will be rejected because the target keeps moving.  Just look back
> at the discussion history:
>
>  . you said you want something done under -q, so I suggested
>    site-start
>  . you then bring up package initialization, which was never
>    mentioned before
>  . I suggest to delay package initialization, but then it turns out
>    you want to load early-init, and now I don't understand why you
>    mentioned -q in the first place
>
> So now I'm completely confused regarding what are you trying to solve
> and why.  May I suggest to describe the problem(s) in more detail?

My apologies.  To clarify:

- I want to run with -q for the usual reasons of ignoring the user's
  early-init.el and init.el.

- While running with -q, I want to do things which can only be done with
  early-init.el, like configuring package initialization,
  load-path-filter-function, or the initial frame parameters.

More simply the problem is:

- I don't want to load the user's early-init.el

- But there are certain things which can only be done via early-init.el

How about this variation on your idea: what if we added a
site-early-start.el which is loaded just before early-init.el, mirroring
how site-start.el is loaded just before init.el?  That would be really
useful for my site in general, for more than just this issue, because it
would allow new kinds of site-wide configuration that is currently
impossible.