Eli Zaretskii <eliz@gnu.org> 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" <bug-gnu-emacs@gnu.org>
>>
>>
>> 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...