On Wed, May 14, 2025 at 1:57 PM Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Eli Zaretskii writes: > > >> From: Spencer Baugh > >> Date: Wed, 14 May 2025 13:07:16 -0400 > >> Cc: 78304@debbugs.gnu.org > >> > >> On Wed, May 14, 2025, 12:26 PM Eli Zaretskii wrote: > >> > >> > From: Spencer Baugh > >> > Date: Wed, 14 May 2025 11:36:40 -0400 > >> > Cc: 78304@debbugs.gnu.org > >> > > >> > On Wed, May 14, 2025, 7:29 AM Eli Zaretskii wrote: > >> > > >> > > From: Spencer Baugh > >> > > Cc: 78304@debbugs.gnu.org > >> > > Date: Tue, 13 May 2025 14:10:24 -0400 > >> > > > >> > > Eli Zaretskii 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?