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

From: Ship Mints <[email-masked]>
Date: Wed, 14 May 2025 14:00:32 -0400

On Wed, May 14, 2025 at 1:57 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]>
> >> Date: Wed, 14 May 2025 13:07:16 -0400
> >> Cc: [email-masked]
> >>
> >> On Wed, May 14, 2025, 12:26 PM Eli Zaretskii <[email-masked]> wrote:
> >>
> >>  > From: Spencer Baugh <[email-masked]>
> >>  > Date: Wed, 14 May 2025 11:36:40 -0400
> >>  > Cc: [email-masked]
> >>  >
> >>  > On Wed, May 14, 2025, 7:29 AM Eli Zaretskii <[email-masked]> wrote:
> >>  >
> >>  >  > From: Spencer Baugh <[email-masked]>
> >>  >  > Cc: [email-masked]
> >>  >  > Date: Tue, 13 May 2025 14:10:24 -0400
> >>  >  >
> >>  >  > Eli Zaretskii <[email-masked]> 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.
>

That's good.  Wouldn't you want both that and a command-line option like
-qe so that you can do this via the command line to aid testing and also
provide Emacs programs that don't rely on site-early-init.el?