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

From: Ship Mints <[email-masked]>
Date: Thu, 8 May 2025 12:41:18 -0400

On Thu, May 8, 2025 at 12:27 PM Spencer Baugh via Bug reports for GNU
Emacs, the Swiss army knife of text editors <[email-masked]> wrote:

> Eli Zaretskii <[email-masked]> writes:
>
> >> Date: Wed, 07 May 2025 17:34:33 -0400
> >> From:  Spencer Baugh via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <[email-masked]>
> >>
> >>
> >> There are many useful things which can only be done by code in
> >> early-init.el.  Such things can't be done by code on the command line,
> >> because --eval runs after init.el has been loaded - much too late to,
> >> for example, configure package.el or set initial frame parameters.
> >>
> >> We should add an --early-eval argument to allow doing things which need
> >> to run at early-init time on the command line.
> >>
> >> I'm happy to add this if that sounds reasonable to others.
> >>
> >> (One extremely hacky alternative is to use --init-directory to point the
> >> user-emacs-directory to a directory which contains an early-init.el
> >> file, then reset user-emacs-directory back to its normal value at the
> >> start of that early-init.el.  But that's quite fragile and much harder)
> >
> > This is a slippery slope.  The initial stages of the startup are a
> > delicate process, basically a kind-of bootstrap, whereby Emacs needs
> > to initialize itself while taking into consideration the various
> > customizations which affect the initialization.  The startup.el code
> > is replete with evidence to that: for example, look how many times we
> > call startup--update-eln-cache, custom-reevaluate-setting and
> > frame-notice-user-settings.
> >
> > We are already on this slippery slope, with early-init file, the
> > '--init-directory' option (which, btw, already shows its subtle
> > unexpected aspects), and other similar enhancements.  This causes
> > numerous bug reports and non-trivial maintenance burden, because
> > people rightfully expect these features to work as a naïve user would
> > expect, without understanding all the subtleties and problematic
> > nature of the startup process.
> >
> > So I'm firmly against extending Emacs in these directions, because the
> > costs far outweigh the advantages, and because requests of this kind
> > usually serve a small number (as in 1) of users who have peculiar
> > desires, while all the rest are perfectly okay with what we already
> > have.
> >
> > If you want this request to be considered seriously, please describe
> > the specific use cases where you think this is needed, and please
> > explain: why you couldn't do this using the existing facilities
> > (including early-init file), and how would the proposed changes serve
> > enough Emacs users to justify the maintenance costs.  Because
> > arguments of the kind "we should add --early-eval" are a huge
> > non-starter for me, since I have some idea how the command-line
> > arguments are processed in Emacs.
> >
> > So, basically: thanks, but no, thanks.  However, I'm open to hear some
> > starking unexpected gap in our features that is entirely impossible to
> > solve unless we add something.
>
> That is reasonable.
>
> The general use case is configuring things which need to be set in
> early-init.el while running "emacs -q".
>
> Two concrete use cases I have that are prompting this idea:
>
> - Working with the new load-path-filter-function variable discussed on
>   emacs-devel.  Since it 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 with emacs -q.
>
> - 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.
>
> The workaround that occurs to me is to run emacs without -q, but instead
> with an --init-directory that contains an early-init.el which does
> whatever configurations I want, and then at the end does
>
> (setq init-file-user nil
>       user-emacs-directory (startup--xdg-or-homedot
> startup--xdg-config-home-emacs nil))
>
> to obtain the same behavior as -q, and also reset user-emacs-directory
> back to its normal value.  Of course, this is hacky and quite fragile...
>

Perhaps adding -qe which would load early-init.el but not init.el loaded
might do?  If -qe filename.el, it could load that file in place of
early-init.el?