GNU bug report logs -
#78304
31.0.50; Support --early-eval on the command line
Previous Next
Full log
Message #14 received at 78304 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, May 8, 2025 at 12:27 PM Spencer Baugh via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:
> 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...
>
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?
[Message part 2 (text/html, inline)]
This bug report was last modified 31 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.