Subject: Re: bug#78304: 31.0.50; Support --early-eval on the command line

From: Ship Mints <[email-masked]>
Date: Fri, 16 May 2025 08:24:07 -0400

On Fri, May 16, 2025 at 8:05 AM Eli Zaretskii <[email-masked]> wrote:

> > From: Ship Mints <[email-masked]>
> > Date: Fri, 16 May 2025 06:22:29 -0400
> > Cc: Lynn Winebarger <[email-masked]>, [email-masked],
> [email-masked]
> >
> > On Fri, May 16, 2025 at 3:12 AM Eli Zaretskii <[email-masked]> 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.