On Thu, May 8, 2025 at 12:27 PM Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Eli Zaretskii 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" > >> > >> > >> 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?