GNU bug report logs -
#78304
31.0.50; Support --early-eval on the command line
Previous Next
Full log
Message #11 received at 78304 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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 <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.
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...
This bug report was last modified 30 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.