Re: on emacs 28 for windows

[Eli Zaretskii]

> Date: Wed, 26 Aug 2020 22:21:11 -0300
> From: Wayne Harris via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> C:\sys\emacs.28\bin>echo %EMACSLOADPATH%
> %EMACSLOADPATH%
> 
> C:\sys\emacs.28\bin>
> 
> That convinces me it's not set.

The canonical test is to say

  C:\sys\emacs.28\bin>set EMACSLOADPATH

That should produce an explicit "not defined" response if the variable
is not defined.

> I don't think my GNU Emacs installations have ever made any changes
> to the Windows registry, but how would I know?  Where would I look?

Start regedit and search for the variable's name with C-f followed by
F3.

> > After you start "emacs -Q", what is the value of load-path?
> 
> ("c:/sys/emacs.28/share/emacs/28.0.50/lisp"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/vc"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/url"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/textmodes"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/progmodes"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/play"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/org"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/nxml"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/net"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/mh-e"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/mail"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/leim"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/language"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/international"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/image"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/gnus"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/eshell"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/erc"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/emulation"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/emacs-lisp"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/cedet"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/calendar"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/calc"
> "c:/sys/emacs.28/share/emacs/28.0.50/lisp/obsolete"
> "c:/msys64/home/Administrator/emacs-build/git/master/lisp")

That last list element is the problem.  I don't know how it gets
there, ideas are welcome.

Phillip, perhaps try stepping with GDB through init_lread and its
subroutines, and see where does this come from.  I expect that to be
the value of PATH_DUMPLOADSEARCH, but it shouldn't be used in a normal
startup of an installed Emacs.  I guess I'm missing something here.
Maybe it's somehow related to the fact that there's no --prefix at
configure time, but I'm not sure.