GNU bug report logs -
#78304
31.0.50; Support --early-eval on the command line
Previous Next
Full log
Message #95 received at 78304 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 16 May 2025 08:24:07 -0400
> Cc: owinebar <at> gmail.com, sbaugh <at> janestreet.com, 78304 <at> debbugs.gnu.org
>
> The documentation for -L doesn't say that it doesn't affect
> site-start.el.
It does now.
> 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.
You cannot expect that, in general. The command-line arguments are
processed in certain unspecified order, some of them in C, others in
Lisp. Those that are processed in Lisp are handled at some stage of
the startup, and it should be clear that before a command-line option
is processed, it cannot take its effect. So it should be clear that
_some_ part of the startup process runs without the effect of the
option. Which part exactly is unspecified, so it is best to consider
the startup process as a single monolith, and assume the options are
in effect only after the startup is done.
Also, EMACSLOADPATH is _not_ the equivalent of -L. The Emacs user
manual says:
‘EMACSLOADPATH’
A colon-separated list of directories(1) to search for Emacs Lisp
files. If set, it modifies the usual initial value of the
‘load-path’ variable (*note Lisp Libraries::).
Note the "initial" part. IOW, EMACSLOADPATH is intended to completely
replace the built-in value of load-path, not to augment it.
In any case, I don't think that this subtle issue is related to the
bug being discussed here. It's a tangent.
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.