On Fri, May 16, 2025 at 8:05 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Ship Mints <shipmints@gmail.com>
> Date: Fri, 16 May 2025 06:22:29 -0400
> Cc: Lynn Winebarger <owinebar@gmail.com>, sbaugh@janestreet.com, 78304@debbugs.gnu.org
>
> On Fri, May 16, 2025 at 3:12 AM Eli Zaretskii <eliz@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.