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
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
This bug report was last modified 30 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.