bug#11959: 24.1.50; Warning: Lisp directory `C:/Emacs-24-2012-07-16/../site-lisp' does not exist.

[Drew Adams]

> The reason for this are the changes made by Glenn in revision 108939.
> Prior to those changes, when load-path was determined by the value of
> EMACSLOADPATH environment variable, the resulting list was never
> checked to verify that every directory there exists.  Now load-path
> determined that way _is_ checked.

May I ask why?  What was the problem with allowing non-existing directories in
`load-path'?  A priori, that sounds like the _right_ thing to do.  And what is
done now whenever one such is encountered - just print a warning?

> The other part of the puzzle is that when Emacs on Windows starts, it
> always defines EMACSLOADPATH and puts 2 site-lisp directories into it:
> one that is in the same tree as the binary, which is supposed to be
> version dependent, and another one that is a sibling of the root of
> the installed tree, which is supposed to be version-independent.

You mean that it does so systematically, in a hard-coded fashion?  Or does it
put those there only if such directories exist?

> This is for compatibility with Emacs on Posix platforms, where we
> also push 2 directories onto load-path:
> /usr/local/share/emacs/XY.Z/site-lisp and
> /usr/local/share/emacs/site-lisp, respectively.  However, unlike
> on Unix, on Windows there's no test whether these directories actually
> exist, because this was never a problem with the old code.
> 
> But now, that the value of EMACSLOADPATH is being checked, we are
> seeing these warnings (unless Emacs is invoked with -Q), and I'm
> guessing that most Emacs users on Windows don't have a
> version-independent site-lisp directory, so most of them will be
> affected.
> 
> It would be easy enough to make sure the site-lisp directories exist
> before adding them to EMACSLOADPATH on Windows.  But before doing so,
> I'd like to understand why was the behavior in init_lread changed so
> as to check EMACSLOADPATH in the first place?

That was my question also.  Just what problem is that trying to solve?

> And if we do want to check that, why not exempt the site-lisp
> directories from the need to exist, like we do in the case where
> EMACSLOADPATH is not set?

Such exceptionalism smacks of fragile design.  What applies to site-lisp might
apply to some other directory as well (tomorrow, if not today).

But I don't have a puppy in this critter crawl - just curious why the change was
made.