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