GNU bug report logs - #78304
31.0.50; Support --early-eval on the command line

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 78304 <at> debbugs.gnu.org
Subject: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Thu, 08 May 2025 08:28:03 +0300

> 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 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.