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

Previous Next

To reply to this bug, email your comments to 78304 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Support --early-eval on the command line
Date: Wed, 07 May 2025 17:34:33 -0400

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)


In GNU Emacs 31.0.50 (build 38, x86_64-pc-linux-gnu, GTK+ Version
 3.22.30, cairo version 1.15.12) of 2025-05-01 built on igm-qws-u22796a
Repository revision: fee7b40efadc3e3ebc62f1f845837cc97bd84606
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)

Configured using:
 'configure -C --with-gif=no'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSELINUX
LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM
XINERAMA XINPUT2 XPM XRANDR GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr compile comint ansi-osc ansi-color ring emacsbug
lisp-mnt message mailcap yank-media puny dired dired-loaddefs rfc822 mml
mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date subr-x mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp-run bytecomp
byte-compile comp-common rx warnings icons cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar regexp-opt rfn-eshadow isearch easymenu timer
select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
tty-child-frames native-compile emacs)

Memory information:
((conses 16 89189 8663) (symbols 48 6857 0) (strings 32 24530 1634)
 (string-bytes 1 814844) (vectors 16 15667)
 (vector-slots 8 187526 6377) (floats 8 35 1) (intervals 56 408 19)
 (buffers 984 12))

Message #8 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: 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.

Message #11 received at 78304 <at> debbugs.gnu.org (full text, mbox):

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

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

Message #14 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Thu, 8 May 2025 12:41:18 -0400

[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)]

Message #17 received at 78304 <at> debbugs.gnu.org (full text, mbox):

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

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 78304 <at> debbugs.gnu.org
> Date: Thu, 08 May 2025 12:26:24 -0400
> 
> 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...

Why cannot you do whatever you need in the site-init file?

Message #20 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Tue, 13 May 2025 14:10:24 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: 78304 <at> debbugs.gnu.org
>> Date: Thu, 08 May 2025 12:26:24 -0400
>> 
>> 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...
>
> Why cannot you do whatever you need in the site-init file?

By that I assume you mean site-start.el, since AFAIK site-init.el is not
loaded at runtime, only at dump time.

As (info "(elisp) Startup Summary") describes, site-start.el is loaded
after package-activate-all is called and the initial frame is set up.
It is therefore loaded too late to configure these things.

(Sorry, accidentally sent my previous reply directly only to Eli)

Message #23 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Tue, 13 May 2025 14:16:20 -0400

Ship Mints <shipmints <at> gmail.com> writes:
> 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?

Yes, something like that would work for me.  Though I would only ever
use the "-qe filename.el" mode.  I'm not sure there's much of a use case
for "-qe" alone, and it might confuse users.

Message #26 received at 78304 <at> debbugs.gnu.org (full text, mbox):

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

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 78304 <at> debbugs.gnu.org
> Date: Tue, 13 May 2025 14:10:24 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Why cannot you do whatever you need in the site-init file?
> 
> By that I assume you mean site-start.el, since AFAIK site-init.el is not
> loaded at runtime, only at dump time.
> 
> As (info "(elisp) Startup Summary") describes, site-start.el is loaded
> after package-activate-all is called and the initial frame is set up.
> It is therefore loaded too late to configure these things.

That's easy to overcome: set package-enable-at-startup to a nil value
in early-init.el, then call package-activate-all in site-start file.

Does this solve the problem?

Message #29 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Wed, 14 May 2025 11:36:40 -0400

[Message part 1 (text/plain, inline)]

On Wed, May 14, 2025, 7:29 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Spencer Baugh <sbaugh <at> janestreet.com>
> > Cc: 78304 <at> debbugs.gnu.org
> > Date: Tue, 13 May 2025 14:10:24 -0400
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > Why cannot you do whatever you need in the site-init file?
> >
> > By that I assume you mean site-start.el, since AFAIK site-init.el is not
> > loaded at runtime, only at dump time.
> >
> > As (info "(elisp) Startup Summary") describes, site-start.el is loaded
> > after package-activate-all is called and the initial frame is set up.
> > It is therefore loaded too late to configure these things.
>
> That's easy to overcome: set package-enable-at-startup to a nil value
> in early-init.el, then call package-activate-all in site-start file.
>
> Does this solve the problem?
>

No, because as I said above, there's no way to combine this solution with
-q.

>

[Message part 2 (text/html, inline)]

Message #32 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Wed, 14 May 2025 19:26:35 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Wed, 14 May 2025 11:36:40 -0400
> Cc: 78304 <at> debbugs.gnu.org
> 
> On Wed, May 14, 2025, 7:29 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>  > From: Spencer Baugh <sbaugh <at> janestreet.com>
>  > Cc: 78304 <at> debbugs.gnu.org
>  > Date: Tue, 13 May 2025 14:10:24 -0400
>  > 
>  > Eli Zaretskii <eliz <at> gnu.org> writes:
>  > 
>  > > Why cannot you do whatever you need in the site-init file?
>  > 
>  > By that I assume you mean site-start.el, since AFAIK site-init.el is not
>  > loaded at runtime, only at dump time.
>  > 
>  > As (info "(elisp) Startup Summary") describes, site-start.el is loaded
>  > after package-activate-all is called and the initial frame is set up.
>  > It is therefore loaded too late to configure these things.
> 
>  That's easy to overcome: set package-enable-at-startup to a nil value
>  in early-init.el, then call package-activate-all in site-start file.
> 
>  Does this solve the problem?
> 
> No, because as I said above, there's no way to combine this solution with -q.

I don't understand why.  The -q switch doesn't disable loading
site-start file.

Message #35 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Wed, 14 May 2025 13:07:16 -0400

[Message part 1 (text/plain, inline)]

On Wed, May 14, 2025, 12:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Spencer Baugh <sbaugh <at> janestreet.com>
> > Date: Wed, 14 May 2025 11:36:40 -0400
> > Cc: 78304 <at> debbugs.gnu.org
> >
> > On Wed, May 14, 2025, 7:29 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> >  > From: Spencer Baugh <sbaugh <at> janestreet.com>
> >  > Cc: 78304 <at> debbugs.gnu.org
> >  > Date: Tue, 13 May 2025 14:10:24 -0400
> >  >
> >  > Eli Zaretskii <eliz <at> gnu.org> writes:
> >  >
> >  > > Why cannot you do whatever you need in the site-init file?
> >  >
> >  > By that I assume you mean site-start.el, since AFAIK site-init.el is
> not
> >  > loaded at runtime, only at dump time.
> >  >
> >  > As (info "(elisp) Startup Summary") describes, site-start.el is loaded
> >  > after package-activate-all is called and the initial frame is set up.
> >  > It is therefore loaded too late to configure these things.
> >
> >  That's easy to overcome: set package-enable-at-startup to a nil value
> >  in early-init.el, then call package-activate-all in site-start file.
> >
> >  Does this solve the problem?
> >
> > No, because as I said above, there's no way to combine this solution
> with -q.
>
> I don't understand why.  The -q switch doesn't disable loading
> site-start file.
>

It disables loading early-init.el.

>

[Message part 2 (text/html, inline)]

Message #38 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Wed, 14 May 2025 20:35:12 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Wed, 14 May 2025 13:07:16 -0400
> Cc: 78304 <at> debbugs.gnu.org
> 
> On Wed, May 14, 2025, 12:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>  > From: Spencer Baugh <sbaugh <at> janestreet.com>
>  > Date: Wed, 14 May 2025 11:36:40 -0400
>  > Cc: 78304 <at> debbugs.gnu.org
>  > 
>  > On Wed, May 14, 2025, 7:29 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>  > 
>  >  > From: Spencer Baugh <sbaugh <at> janestreet.com>
>  >  > Cc: 78304 <at> debbugs.gnu.org
>  >  > Date: Tue, 13 May 2025 14:10:24 -0400
>  >  > 
>  >  > Eli Zaretskii <eliz <at> gnu.org> writes:
>  >  > 
>  >  > > Why cannot you do whatever you need in the site-init file?
>  >  > 
>  >  > By that I assume you mean site-start.el, since AFAIK site-init.el is not
>  >  > loaded at runtime, only at dump time.
>  >  > 
>  >  > As (info "(elisp) Startup Summary") describes, site-start.el is loaded
>  >  > after package-activate-all is called and the initial frame is set up.
>  >  > It is therefore loaded too late to configure these things.
>  > 
>  >  That's easy to overcome: set package-enable-at-startup to a nil value
>  >  in early-init.el, then call package-activate-all in site-start file.
>  > 
>  >  Does this solve the problem?
>  > 
>  > No, because as I said above, there's no way to combine this solution with -q.
> 
>  I don't understand why.  The -q switch doesn't disable loading
>  site-start file.
> 
> It disables loading early-init.el.

And why is that a problem in this case?

IOW, you seem to be describing several different situations, but each
one of them might need a slightly different solution.  E.g., you never
explained why you want to do whatever you need to do in "emacs -q".

Given all these undisclosed details and rationales, it is hard to have
a useful and efficient discussion.  I almost feel like the rules of
the game change with each new message, and no matter what I suggest,
it will be rejected because the target keeps moving.  Just look back
at the discussion history:

 . you said you want something done under -q, so I suggested
   site-start
 . you then bring up package initialization, which was never
   mentioned before
 . I suggest to delay package initialization, but then it turns out
   you want to load early-init, and now I don't understand why you
   mentioned -q in the first place

So now I'm completely confused regarding what are you trying to solve
and why.  May I suggest to describe the problem(s) in more detail?

Message #41 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Wed, 14 May 2025 13:56:08 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Date: Wed, 14 May 2025 13:07:16 -0400
>> Cc: 78304 <at> debbugs.gnu.org
>> 
>> On Wed, May 14, 2025, 12:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 
>>  > From: Spencer Baugh <sbaugh <at> janestreet.com>
>>  > Date: Wed, 14 May 2025 11:36:40 -0400
>>  > Cc: 78304 <at> debbugs.gnu.org
>>  > 
>>  > On Wed, May 14, 2025, 7:29 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>  > 
>>  >  > From: Spencer Baugh <sbaugh <at> janestreet.com>
>>  >  > Cc: 78304 <at> debbugs.gnu.org
>>  >  > Date: Tue, 13 May 2025 14:10:24 -0400
>>  >  > 
>>  >  > Eli Zaretskii <eliz <at> gnu.org> writes:
>>  >  > 
>>  >  > > Why cannot you do whatever you need in the site-init file?
>>  >  > 
>>  >  > By that I assume you mean site-start.el, since AFAIK site-init.el is not
>>  >  > loaded at runtime, only at dump time.
>>  >  > 
>>  >  > As (info "(elisp) Startup Summary") describes, site-start.el is loaded
>>  >  > after package-activate-all is called and the initial frame is set up.
>>  >  > It is therefore loaded too late to configure these things.
>>  > 
>>  >  That's easy to overcome: set package-enable-at-startup to a nil value
>>  >  in early-init.el, then call package-activate-all in site-start file.
>>  > 
>>  >  Does this solve the problem?
>>  > 
>>  > No, because as I said above, there's no way to combine this solution with -q.
>> 
>>  I don't understand why.  The -q switch doesn't disable loading
>>  site-start file.
>> 
>> It disables loading early-init.el.
>
> And why is that a problem in this case?
>
> IOW, you seem to be describing several different situations, but each
> one of them might need a slightly different solution.  E.g., you never
> explained why you want to do whatever you need to do in "emacs -q".
>
> Given all these undisclosed details and rationales, it is hard to have
> a useful and efficient discussion.  I almost feel like the rules of
> the game change with each new message, and no matter what I suggest,
> it will be rejected because the target keeps moving.  Just look back
> at the discussion history:
>
>  . you said you want something done under -q, so I suggested
>    site-start
>  . you then bring up package initialization, which was never
>    mentioned before
>  . I suggest to delay package initialization, but then it turns out
>    you want to load early-init, and now I don't understand why you
>    mentioned -q in the first place
>
> So now I'm completely confused regarding what are you trying to solve
> and why.  May I suggest to describe the problem(s) in more detail?

My apologies.  To clarify:

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

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

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.

Message #44 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Wed, 14 May 2025 14:00:32 -0400

[Message part 1 (text/plain, inline)]

On Wed, May 14, 2025 at 1:57 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:
>
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Date: Wed, 14 May 2025 13:07:16 -0400
> >> Cc: 78304 <at> debbugs.gnu.org
> >>
> >> On Wed, May 14, 2025, 12:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>
> >>  > From: Spencer Baugh <sbaugh <at> janestreet.com>
> >>  > Date: Wed, 14 May 2025 11:36:40 -0400
> >>  > Cc: 78304 <at> debbugs.gnu.org
> >>  >
> >>  > On Wed, May 14, 2025, 7:29 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>  >
> >>  >  > From: Spencer Baugh <sbaugh <at> janestreet.com>
> >>  >  > Cc: 78304 <at> debbugs.gnu.org
> >>  >  > Date: Tue, 13 May 2025 14:10:24 -0400
> >>  >  >
> >>  >  > Eli Zaretskii <eliz <at> gnu.org> writes:
> >>  >  >
> >>  >  > > Why cannot you do whatever you need in the site-init file?
> >>  >  >
> >>  >  > By that I assume you mean site-start.el, since AFAIK site-init.el
> is not
> >>  >  > loaded at runtime, only at dump time.
> >>  >  >
> >>  >  > As (info "(elisp) Startup Summary") describes, site-start.el is
> loaded
> >>  >  > after package-activate-all is called and the initial frame is set
> up.
> >>  >  > It is therefore loaded too late to configure these things.
> >>  >
> >>  >  That's easy to overcome: set package-enable-at-startup to a nil
> value
> >>  >  in early-init.el, then call package-activate-all in site-start file.
> >>  >
> >>  >  Does this solve the problem?
> >>  >
> >>  > No, because as I said above, there's no way to combine this solution
> with -q.
> >>
> >>  I don't understand why.  The -q switch doesn't disable loading
> >>  site-start file.
> >>
> >> It disables loading early-init.el.
> >
> > And why is that a problem in this case?
> >
> > IOW, you seem to be describing several different situations, but each
> > one of them might need a slightly different solution.  E.g., you never
> > explained why you want to do whatever you need to do in "emacs -q".
> >
> > Given all these undisclosed details and rationales, it is hard to have
> > a useful and efficient discussion.  I almost feel like the rules of
> > the game change with each new message, and no matter what I suggest,
> > it will be rejected because the target keeps moving.  Just look back
> > at the discussion history:
> >
> >  . you said you want something done under -q, so I suggested
> >    site-start
> >  . you then bring up package initialization, which was never
> >    mentioned before
> >  . I suggest to delay package initialization, but then it turns out
> >    you want to load early-init, and now I don't understand why you
> >    mentioned -q in the first place
> >
> > So now I'm completely confused regarding what are you trying to solve
> > and why.  May I suggest to describe the problem(s) in more detail?
>
> My apologies.  To clarify:
>
> - 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.
>
> 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
>
> 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.
>

That's good.  Wouldn't you want both that and a command-line option like
-qe so that you can do this via the command line to aid testing and also
provide Emacs programs that don't rely on site-early-init.el?

[Message part 2 (text/html, inline)]

Message #47 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Wed, 14 May 2025 14:34:52 -0400

Ship Mints <shipmints <at> gmail.com> writes:

> On Wed, May 14, 2025 at 1:57 PM Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
> <bug-gnu-emacs <at> gnu.org> wrote:
>  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.
>
> That's good.  Wouldn't you want both that and a command-line option like -qe so that you can do this via the command line to aid
> testing and also provide Emacs programs that don't rely on site-early-init.el?

No, site-early-init.el would remove the need for -qe: simply export the
environment variable "EMACSLOADPATH=somedir:" where somedir contains a
site-early-init.el file which has the code you want to run "early", and
then pass -q as normal.

More awkward, of course, but it would work fine.

Message #50 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Wed, 14 May 2025 14:40:53 -0400

[Message part 1 (text/plain, inline)]

On Wed, May 14, 2025 at 2:34 PM Spencer Baugh <sbaugh <at> janestreet.com> wrote:

> Ship Mints <shipmints <at> gmail.com> writes:
>
> > On Wed, May 14, 2025 at 1:57 PM Spencer Baugh via Bug reports for GNU
> Emacs, the Swiss army knife of text editors
> > <bug-gnu-emacs <at> gnu.org> wrote:
> >  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.
> >
> > That's good.  Wouldn't you want both that and a command-line option like
> -qe so that you can do this via the command line to aid
> > testing and also provide Emacs programs that don't rely on
> site-early-init.el?
>
> No, site-early-init.el would remove the need for -qe: simply export the
> environment variable "EMACSLOADPATH=somedir:" where somedir contains a
> site-early-init.el file which has the code you want to run "early", and
> then pass -q as normal.
>
> More awkward, of course, but it would work fine.
>

And a little less discoverable.

[Message part 2 (text/html, inline)]

Message #53 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: 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.

Message #56 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Thu, 15 May 2025 09:41:31 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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?

Two concrete use cases:

- Since load-path-filter-function 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 and test 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.

Message #59 received at 78304 <at> debbugs.gnu.org (full text, mbox):

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

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 78304 <at> debbugs.gnu.org
> Date: Thu, 15 May 2025 09:41:31 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> 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?
> 
> Two concrete use cases:
> 
> - Since load-path-filter-function 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 and test it with emacs -q.

Since early-init.el is not supposed to load anything, only set up some
variables, I don't understand why you insist on doing this in
early-init.  The site-start file is loaded right after early-init.el,
so if you set that up at the very beginning of site-start file, it
will have the same effect.

And even if that doesn't work for some reason I cannot imagine ATM,
you could do this in site-start when Emacs was invoked with -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.

Same question here: why cannot this be done in site-start file?  IMO,
it is even cleaner, because it doesn't require each user to do the
same in their early-init files; instead, you will do that only once
for all of them.

Message #62 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Thu, 15 May 2025 12:19:16 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: 78304 <at> debbugs.gnu.org
>> Date: Thu, 15 May 2025 09:41:31 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> 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?
>> 
>> Two concrete use cases:
>> 
>> - Since load-path-filter-function 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 and test it with emacs -q.
>
> Since early-init.el is not supposed to load anything, only set up some
> variables, I don't understand why you insist on doing this in
> early-init.  The site-start file is loaded right after early-init.el,
> so if you set that up at the very beginning of site-start file, it
> will have the same effect.

That is not the case: Many things happen, including loading of files,
between site-start and early-init.  Package initialization and initial
frame setup, for example.

>> - 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.
>
> Same question here: why cannot this be done in site-start file?  IMO,
> it is even cleaner, because it doesn't require each user to do the
> same in their early-init files; instead, you will do that only once
> for all of them.

Because initial frame setup happens before site-start is loaded.

Message #65 received at 78304 <at> debbugs.gnu.org (full text, mbox):

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

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 78304 <at> debbugs.gnu.org
> Date: Thu, 15 May 2025 12:19:16 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > Why do you want to do that under -q?
> >> 
> >> Two concrete use cases:
> >> 
> >> - Since load-path-filter-function 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 and test it with emacs -q.
> >
> > Since early-init.el is not supposed to load anything, only set up some
> > variables, I don't understand why you insist on doing this in
> > early-init.  The site-start file is loaded right after early-init.el,
> > so if you set that up at the very beginning of site-start file, it
> > will have the same effect.
> 
> That is not the case: Many things happen, including loading of files,
> between site-start and early-init.  Package initialization and initial
> frame setup, for example.

And why is that important in your cases, again?  You never said
anything about packages and frame initialization.

> >> - 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.
> >
> > Same question here: why cannot this be done in site-start file?  IMO,
> > it is even cleaner, because it doesn't require each user to do the
> > same in their early-init files; instead, you will do that only once
> > for all of them.
> 
> Because initial frame setup happens before site-start is loaded.

So now please explain why that is an issue in -q invocations.

Bonus points for explaining why you need all this to run under -q.
Because if you could do this without -q, all the problems will
magically disappear, right?

Message #68 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Thu, 15 May 2025 13:05:14 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: 78304 <at> debbugs.gnu.org
>> Date: Thu, 15 May 2025 12:19:16 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> > Why do you want to do that under -q?
>> >> 
>> >> Two concrete use cases:
>> >> 
>> >> - Since load-path-filter-function 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 and test it with emacs -q.
>> >
>> > Since early-init.el is not supposed to load anything, only set up some
>> > variables, I don't understand why you insist on doing this in
>> > early-init.  The site-start file is loaded right after early-init.el,
>> > so if you set that up at the very beginning of site-start file, it
>> > will have the same effect.
>> 
>> That is not the case: Many things happen, including loading of files,
>> between site-start and early-init.  Package initialization and initial
>> frame setup, for example.
>
> And why is that important in your cases, again?  You never said
> anything about packages and frame initialization.

Because load-path-filter-function affects loading of files, so it
affects anything that causes loading of files, which includes packages
and frame initialization.

Those things happen before site-start.

Therefore, for load-path-filter-function to affect those things (which
is desirable, it's a performance optimization that will speed them up)
it needs to be set before those things.

>> >> - 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.
>> >
>> > Same question here: why cannot this be done in site-start file?  IMO,
>> > it is even cleaner, because it doesn't require each user to do the
>> > same in their early-init files; instead, you will do that only once
>> > for all of them.
>> 
>> Because initial frame setup happens before site-start is loaded.
>
> So now please explain why that is an issue in -q invocations.

When invoking Emacs with -q:

- Initial frame setup happens before site-start is loaded.
- Therefore, initial frame setup cannot be customized in site-start.
- Therefore, I cannot do the things I want to do with site-start.

(This all also holds without -q)

Message #71 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Lynn Winebarger <owinebar <at> gmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Thu, 15 May 2025 13:33:19 -0400

On Thu, May 15, 2025 at 1:06 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:
>
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Cc: 78304 <at> debbugs.gnu.org
> >> Date: Thu, 15 May 2025 12:19:16 -0400
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> >> > Why do you want to do that under -q?
> >> >>
> >> >> Two concrete use cases:
> >> >>
> >> >> - Since load-path-filter-function 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 and test it with emacs -q.
> >> >
> >> > Since early-init.el is not supposed to load anything, only set up some
> >> > variables, I don't understand why you insist on doing this in
> >> > early-init.  The site-start file is loaded right after early-init.el,
> >> > so if you set that up at the very beginning of site-start file, it
> >> > will have the same effect.
> >>
> >> That is not the case: Many things happen, including loading of files,
> >> between site-start and early-init.  Package initialization and initial
> >> frame setup, for example.
> >
> > And why is that important in your cases, again?  You never said
> > anything about packages and frame initialization.
>
> Because load-path-filter-function affects loading of files, so it
> affects anything that causes loading of files, which includes packages
> and frame initialization.
>
> Those things happen before site-start.
>
> Therefore, for load-path-filter-function to affect those things (which
> is desirable, it's a performance optimization that will speed them up)
> it needs to be set before those things.
>
> >> >> - 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.
> >> >
> >> > Same question here: why cannot this be done in site-start file?  IMO,
> >> > it is even cleaner, because it doesn't require each user to do the
> >> > same in their early-init files; instead, you will do that only once
> >> > for all of them.
> >>
> >> Because initial frame setup happens before site-start is loaded.
> >
> > So now please explain why that is an issue in -q invocations.
>
> When invoking Emacs with -q:
>
> - Initial frame setup happens before site-start is loaded.
> - Therefore, initial frame setup cannot be customized in site-start.
> - Therefore, I cannot do the things I want to do with site-start.
>
> (This all also holds without -q)

You could always write a "site-init.el" or "site-load.el" at build
time that will loaded by "loadup.el" during the dump process.  You can
add a function to 'after-pdump-load-hook, which will be run by the C
runtime immediately after the dump file is loaded, before any of the
normal startup code (from startup.el) is run, even before the top
level recursive-edit is called.  You can redefine the "top-level"
function to do whatever you want for your site.

Lynn

Message #74 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Lynn Winebarger <owinebar <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Thu, 15 May 2025 15:08:34 -0400

Lynn Winebarger <owinebar <at> gmail.com> writes:
> On Thu, May 15, 2025 at 1:06 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:
>>
>> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> >> Cc: 78304 <at> debbugs.gnu.org
>> >> Date: Thu, 15 May 2025 12:19:16 -0400
>> >>
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >>
>> >> >> > Why do you want to do that under -q?
>> >> >>
>> >> >> Two concrete use cases:
>> >> >>
>> >> >> - Since load-path-filter-function 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 and test it with emacs -q.
>> >> >
>> >> > Since early-init.el is not supposed to load anything, only set up some
>> >> > variables, I don't understand why you insist on doing this in
>> >> > early-init.  The site-start file is loaded right after early-init.el,
>> >> > so if you set that up at the very beginning of site-start file, it
>> >> > will have the same effect.
>> >>
>> >> That is not the case: Many things happen, including loading of files,
>> >> between site-start and early-init.  Package initialization and initial
>> >> frame setup, for example.
>> >
>> > And why is that important in your cases, again?  You never said
>> > anything about packages and frame initialization.
>>
>> Because load-path-filter-function affects loading of files, so it
>> affects anything that causes loading of files, which includes packages
>> and frame initialization.
>>
>> Those things happen before site-start.
>>
>> Therefore, for load-path-filter-function to affect those things (which
>> is desirable, it's a performance optimization that will speed them up)
>> it needs to be set before those things.
>>
>> >> >> - 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.
>> >> >
>> >> > Same question here: why cannot this be done in site-start file?  IMO,
>> >> > it is even cleaner, because it doesn't require each user to do the
>> >> > same in their early-init files; instead, you will do that only once
>> >> > for all of them.
>> >>
>> >> Because initial frame setup happens before site-start is loaded.
>> >
>> > So now please explain why that is an issue in -q invocations.
>>
>> When invoking Emacs with -q:
>>
>> - Initial frame setup happens before site-start is loaded.
>> - Therefore, initial frame setup cannot be customized in site-start.
>> - Therefore, I cannot do the things I want to do with site-start.
>>
>> (This all also holds without -q)
>
> You could always write a "site-init.el" or "site-load.el" at build
> time that will loaded by "loadup.el" during the dump process.  You can
> add a function to 'after-pdump-load-hook, which will be run by the C
> runtime immediately after the dump file is loaded, before any of the
> normal startup code (from startup.el) is run, even before the top
> level recursive-edit is called.  You can redefine the "top-level"
> function to do whatever you want for your site.

That's true enough, but this is not about my site - the only reason site
files came up is because Eli mentioned them.  Both of the use cases I
mentioned (setting load-path-filter-function, using a script to run a
reduced-functionality Emacs) should work for users anywhere without
requring them to compile their own Emacs.

Message #77 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Lynn Winebarger <owinebar <at> gmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Thu, 15 May 2025 15:51:22 -0400

[Message part 1 (text/plain, inline)]

On Thu, May 15, 2025, 3:08 PM Spencer Baugh <sbaugh <at> janestreet.com> wrote:

> Lynn Winebarger <owinebar <at> gmail.com> writes:
>
> That's true enough, but this is not about my site - the only reason site
> files came up is because Eli mentioned them.  Both of the use cases I
> mentioned (setting load-path-filter-function, using a script to run a
> reduced-functionality Emacs) should work for users anywhere without
> requring them to compile their own Emacs.
>

The only thing I can suggest is working to ensure redumping is functional,
since (rereading the email chain) you seem to be working on specialized
instances of emacs.  But you don't even really need that.

You can make an installation script that either redumps or just dumps, you
don't have to recompile anything.  Just install a script that calls emacs
with the explicit flag for the dump file the installation script
generates.  Everything necessary will already be available with the system,
dumping just loads the stuff you specify, then does a specialized garbage
collection and saves the result.  Pretty much any reasonable package
management system should allow you to do what's needed at install time.

I think you'll find that a much easier path to your goal than convincing
Eli to add another feature to maintain.

Lynn

[Message part 2 (text/html, inline)]

Message #80 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Fri, 16 May 2025 09:10:50 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 78304 <at> debbugs.gnu.org
> Date: Thu, 15 May 2025 13:05:14 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > Since early-init.el is not supposed to load anything, only set up some
> >> > variables, I don't understand why you insist on doing this in
> >> > early-init.  The site-start file is loaded right after early-init.el,
> >> > so if you set that up at the very beginning of site-start file, it
> >> > will have the same effect.
> >> 
> >> That is not the case: Many things happen, including loading of files,
> >> between site-start and early-init.  Package initialization and initial
> >> frame setup, for example.
> >
> > And why is that important in your cases, again?  You never said
> > anything about packages and frame initialization.
> 
> Because load-path-filter-function affects loading of files, so it
> affects anything that causes loading of files, which includes packages
> and frame initialization.
> 
> Those things happen before site-start.
> 
> Therefore, for load-path-filter-function to affect those things (which
> is desirable, it's a performance optimization that will speed them up)
> it needs to be set before those things.

This problem disappears if you don't use -q, so it sounds like your
desire to use -q is the culprit.  I don't see why do you need -q, and
you still haven't explained the reasons for that.

> >> >> - 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.
> >> >
> >> > Same question here: why cannot this be done in site-start file?  IMO,
> >> > it is even cleaner, because it doesn't require each user to do the
> >> > same in their early-init files; instead, you will do that only once
> >> > for all of them.
> >> 
> >> Because initial frame setup happens before site-start is loaded.
> >
> > So now please explain why that is an issue in -q invocations.
> 
> When invoking Emacs with -q:
> 
> - Initial frame setup happens before site-start is loaded.
> - Therefore, initial frame setup cannot be customized in site-start.
> - Therefore, I cannot do the things I want to do with site-start.

What frame-setup customizations are we talking about?

> (This all also holds without -q)

Without -q, early-init.el _is_ loaded, so whatever you need to do can
be done there.

So, once again, please explain why you insist on using -q.

Message #83 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lynn Winebarger <owinebar <at> gmail.com>
Cc: sbaugh <at> janestreet.com, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Fri, 16 May 2025 10:10:59 +0300

> From: Lynn Winebarger <owinebar <at> gmail.com>
> Date: Thu, 15 May 2025 15:51:22 -0400
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 78304 <at> debbugs.gnu.org
> 
> On Thu, May 15, 2025, 3:08 PM Spencer Baugh <sbaugh <at> janestreet.com> wrote:
> 
>  Lynn Winebarger <owinebar <at> gmail.com> writes:
> 
>  That's true enough, but this is not about my site - the only reason site
>  files came up is because Eli mentioned them.  Both of the use cases I
>  mentioned (setting load-path-filter-function, using a script to run a
>  reduced-functionality Emacs) should work for users anywhere without
>  requring them to compile their own Emacs.
> 
> The only thing I can suggest is working to ensure redumping is functional, since (rereading the email chain)
> you seem to be working on specialized instances of emacs.  But you don't even really need that.
> 
> You can make an installation script that either redumps or just dumps, you don't have to recompile anything.
>  Just install a script that calls emacs with the explicit flag for the dump file the installation script generates. 
> Everything necessary will already be available with the system, dumping just loads the stuff you specify, then
> does a specialized garbage collection and saves the result.  Pretty much any reasonable package
> management system should allow you to do what's needed at install time.
> 
> I think you'll find that a much easier path to your goal than convincing Eli to add another feature to maintain.

Actually, I think everything Spencer wants to do is achievable via
site-start file, and it's the unnecessary urge to use -q that creates
the problem he tries to solve.  I don't think anything like customized
dumping is needed to solve this problem.

Message #86 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, Lynn Winebarger <owinebar <at> gmail.com>,
 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Fri, 16 May 2025 06:22:29 -0400

[Message part 1 (text/plain, inline)]

On Fri, May 16, 2025 at 3:12 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Lynn Winebarger <owinebar <at> gmail.com>
> > Date: Thu, 15 May 2025 15:51:22 -0400
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 78304 <at> debbugs.gnu.org
> >
> > On Thu, May 15, 2025, 3:08 PM Spencer Baugh <sbaugh <at> janestreet.com>
> wrote:
> >
> >  Lynn Winebarger <owinebar <at> gmail.com> writes:
> >
> >  That's true enough, but this is not about my site - the only reason site
> >  files came up is because Eli mentioned them.  Both of the use cases I
> >  mentioned (setting load-path-filter-function, using a script to run a
> >  reduced-functionality Emacs) should work for users anywhere without
> >  requring them to compile their own Emacs.
> >
> > The only thing I can suggest is working to ensure redumping is
> functional, since (rereading the email chain)
> > you seem to be working on specialized instances of emacs.  But you don't
> even really need that.
> >
> > You can make an installation script that either redumps or just dumps,
> you don't have to recompile anything.
> >  Just install a script that calls emacs with the explicit flag for the
> dump file the installation script generates.
> > Everything necessary will already be available with the system, dumping
> just loads the stuff you specify, then
> > does a specialized garbage collection and saves the result.  Pretty much
> any reasonable package
> > management system should allow you to do what's needed at install time.
> >
> > I think you'll find that a much easier path to your goal than convincing
> Eli to add another feature to maintain.
>
> Actually, I think everything Spencer wants to do is achievable via
> site-start file, and it's the unnecessary urge to use -q that creates
> the problem he tries to solve.  I don't think anything like customized
> dumping is needed to solve this problem.
>

Perhaps I need more coffee...I just tried (on master):

  echo '(defvar BOO "BOO")' > site-start.el
  emacs -L $PWD -q

and ./site-start.el was not loaded.

I read through startup.el and it looks like this should work.  I'd use this
technique to use a script-specific site-start.el file (independent of any
system-wide site-start) for a few Emacs scripts for which I'd want to do
something similar to what Spencer is attempting.

[Message part 2 (text/html, inline)]

Message #89 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: sbaugh <at> janestreet.com, owinebar <at> gmail.com, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Fri, 16 May 2025 15:05:28 +0300

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 16 May 2025 06:22:29 -0400
> Cc: Lynn Winebarger <owinebar <at> gmail.com>, sbaugh <at> janestreet.com, 78304 <at> debbugs.gnu.org
> 
> On Fri, May 16, 2025 at 3:12 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>  Actually, I think everything Spencer wants to do is achievable via
>  site-start file, and it's the unnecessary urge to use -q that creates
>  the problem he tries to solve.  I don't think anything like customized
>  dumping is needed to solve this problem.
> 
> Perhaps I need more coffee...I just tried (on master):
> 
>   echo '(defvar BOO "BOO")' > site-start.el
>   emacs -L $PWD -q
> 
> and ./site-start.el was not loaded.

It isn't supposed to work.  site-start file is looked along load-path,
and the -L switch modifies load-path _after_ Emacs attempts to load
the site-start file.  IOW, the -L switch is intended to affect the
Emacs session after startup.

I said at the beginning of this discussion that the startup process is
delicate and fragile due to its bootstrap-like nature.  So messing
with it will frequently surprise too-naïve expectations.  I wish
people believed me when I say that.

Message #92 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, owinebar <at> gmail.com, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Fri, 16 May 2025 08:24:07 -0400

[Message part 1 (text/plain, inline)]

On Fri, May 16, 2025 at 8:05 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Fri, 16 May 2025 06:22:29 -0400
> > Cc: Lynn Winebarger <owinebar <at> gmail.com>, sbaugh <at> janestreet.com,
> 78304 <at> debbugs.gnu.org
> >
> > On Fri, May 16, 2025 at 3:12 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> >  Actually, I think everything Spencer wants to do is achievable via
> >  site-start file, and it's the unnecessary urge to use -q that creates
> >  the problem he tries to solve.  I don't think anything like customized
> >  dumping is needed to solve this problem.
> >
> > Perhaps I need more coffee...I just tried (on master):
> >
> >   echo '(defvar BOO "BOO")' > site-start.el
> >   emacs -L $PWD -q
> >
> > and ./site-start.el was not loaded.
>
> It isn't supposed to work.  site-start file is looked along load-path,
> and the -L switch modifies load-path _after_ Emacs attempts to load
> the site-start file.  IOW, the -L switch is intended to affect the
> Emacs session after startup.
>
> I said at the beginning of this discussion that the startup process is
> delicate and fragile due to its bootstrap-like nature.  So messing
> with it will frequently surprise too-naïve expectations.  I wish
> people believed me when I say that.
>

I appreciate the delicacy of bootstrapping.  The documentation for -L
doesn't say that it doesn't affect site-start.el.  If one specifies
EMACSLOADPATH before starting Emacs, that does work to find site-start.el,
ignoring whatever system-wide site-start.el exists (which is what I'd
want).  I expected the behavior of -L and EMACSLOADPATH to be in sync.

[Message part 2 (text/html, inline)]

Message #95 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: sbaugh <at> janestreet.com, owinebar <at> gmail.com, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Fri, 16 May 2025 15:42:11 +0300

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 16 May 2025 08:24:07 -0400
> Cc: owinebar <at> gmail.com, sbaugh <at> janestreet.com, 78304 <at> debbugs.gnu.org
> 
> The documentation for -L doesn't say that it doesn't affect
> site-start.el.

It does now.

> If one specifies EMACSLOADPATH before starting Emacs, that does work to find site-start.el,
> ignoring whatever system-wide site-start.el exists (which is what I'd want).  I expected the behavior of -L and
> EMACSLOADPATH to be in sync.

You cannot expect that, in general.  The command-line arguments are
processed in certain unspecified order, some of them in C, others in
Lisp.  Those that are processed in Lisp are handled at some stage of
the startup, and it should be clear that before a command-line option
is processed, it cannot take its effect.  So it should be clear that
_some_ part of the startup process runs without the effect of the
option.  Which part exactly is unspecified, so it is best to consider
the startup process as a single monolith, and assume the options are
in effect only after the startup is done.

Also, EMACSLOADPATH is _not_ the equivalent of -L.  The Emacs user
manual says:

  ‘EMACSLOADPATH’
       A colon-separated list of directories(1) to search for Emacs Lisp
       files.  If set, it modifies the usual initial value of the
       ‘load-path’ variable (*note Lisp Libraries::).

Note the "initial" part.  IOW, EMACSLOADPATH is intended to completely
replace the built-in value of load-path, not to augment it.

In any case, I don't think that this subtle issue is related to the
bug being discussed here.  It's a tangent.

Message #98 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Lynn Winebarger <owinebar <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Fri, 16 May 2025 11:14:49 -0400

On Fri, May 16, 2025 at 3:11 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Actually, I think everything Spencer wants to do is achievable via
> site-start file, and it's the unnecessary urge to use -q that creates
> the problem he tries to solve.  I don't think anything like customized
> dumping is needed to solve this problem.

I'm just taking Spencer's problem description at face-value.
One of Spencer's use cases (the primary one, I thought) is to create
"a script" that will run a "reduced-functionality" mode, particularly:
>>>   [...] 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.

The standard emacs startup is designed to ensure users can override
site defaults without too much effort.  From (elisp)Building Emacs:

>>    It is not advisable to put anything in ‘site-load.el’ or
>> ‘site-init.el’ that would alter any of the features that users expect in
>> an ordinary unmodified Emacs.  If you feel you must override normal
>> features for your site, do it with ‘default.el’, so that users can
>> override your changes if they wish.  [...]

What Spencer is describing is a use-case where users get a custom
presentation of emacs that would indeed "alter any of the features
that users expect in an ordinary unmodified Emacs".  That's why he
wants to use "-q", because the customizations of an ordinary emacs
session are not suited to the purpose of the particular presentation.
The most (probably only) foolproof way of doing that is writing a
custom startup and maybe even the top-level, depending on just how
reduced the functionality is supposed to be.  That approach also has
the advantage of working with many versions of Emacs packages in
versions of Linux distros that haven't hit EOL (i.e. >= 25 or so,
whenever the portable dumper became standard) .  As you mentioned in
another response to this bug, the standard startup process has changed
over those releases, but most of it (except the really low-level bits)
are done in lisp, so those parts can be simplified or changed
arbitrarily to suit the use.  Of course, the wrapper script will have
to intercept any arguments that would be processed by the C runtime
startup, such as "-h","-temacs", etc

Lynn

Message #101 received at 78304 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lynn Winebarger <owinebar <at> gmail.com>
Cc: sbaugh <at> janestreet.com, 78304 <at> debbugs.gnu.org
Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line
Date: Fri, 16 May 2025 20:57:18 +0300

> From: Lynn Winebarger <owinebar <at> gmail.com>
> Date: Fri, 16 May 2025 11:14:49 -0400
> Cc: sbaugh <at> janestreet.com, 78304 <at> debbugs.gnu.org
> 
> On Fri, May 16, 2025 at 3:11 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>    It is not advisable to put anything in ‘site-load.el’ or
> >> ‘site-init.el’ that would alter any of the features that users expect in
> >> an ordinary unmodified Emacs.  If you feel you must override normal
> >> features for your site, do it with ‘default.el’, so that users can
> >> override your changes if they wish.  [...]
> 
> What Spencer is describing is a use-case where users get a custom
> presentation of emacs that would indeed "alter any of the features
> that users expect in an ordinary unmodified Emacs".  That's why he
> wants to use "-q", because the customizations of an ordinary emacs
> session are not suited to the purpose of the particular presentation.

That is easy to accomplish by other means (assuming that it's the
reason, which I'm not sure, because Spencer himself didn't say so).

> The most (probably only) foolproof way of doing that is writing a
> custom startup and maybe even the top-level, depending on just how
> reduced the functionality is supposed to be.

I'm quite sure there are easier ways of accomplishing the same goal.

Previous Next

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