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, 15 May 2025 09:06:27 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 78304 <at> debbugs.gnu.org
> Date: Wed, 14 May 2025 13:56:08 -0400
> 
> - I want to run with -q for the usual reasons of ignoring the user's
>   early-init.el and init.el.
> 
> - While running with -q, I want to do things which can only be done with
>   early-init.el, like configuring package initialization,
>   load-path-filter-function, or the initial frame parameters.

Why do you want to do that under -q?

> More simply the problem is:
> 
> - I don't want to load the user's early-init.el
> 
> - But there are certain things which can only be done via early-init.el

Like what?  Please be specific.  The reason for having early-init is
primarily to affect how the regular init file is loaded and processed.
But -q disables loading the init files, so why do you still need
early-init?  And why cannot you do in site-start whatever you want
done in early-init under -q?

> How about this variation on your idea: what if we added a
> site-early-start.el which is loaded just before early-init.el, mirroring
> how site-start.el is loaded just before init.el?  That would be really
> useful for my site in general, for more than just this issue, because it
> would allow new kinds of site-wide configuration that is currently
> impossible.

I'd like first to have a very good understanding why the existing
features cannot support your use case, so that introduction of new
features in this area is avoided as much as possible, for the reasons
I explained up-thread.

Previous Next

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