[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11959: 24.1.50; Warning: Lisp directory `C:/Emacs-24-2012-07-16/../s

From: Glenn Morris
Subject: bug#11959: 24.1.50; Warning: Lisp directory `C:/Emacs-24-2012-07-16/../site-lisp' does not exist.
Date: Sun, 29 Jul 2012 19:50:28 -0400
User-agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)

Eli Zaretskii wrote:

> It would be easy enough to make sure the site-lisp directories exist
> before adding them to EMACSLOADPATH on Windows. 

That's probably the simplest solution.
Or make the install create them, as the POSIX installation does.

Actually, my recommendation would be to stop setting EMACSLOADPATH (and
the other EMACS* environment variables...) on MS Windows, similar to
what I recently did for the NS port. The only time I ever hear about
EMACSLOADPATH is it causing subtle problems (eg building one version of
Emacs within another, the recent several uni-mirror related startup
failures, I'm guessing).

> 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?

Because I saw no reason to treat EMACSLOADPATH directories differently
to the normal directories. Users should still be warned if they are
missing. (I guess very few people are using EMACSLOADPATH
intentionally though.)

> 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?

Because I assumed people setting EMACSLOADPATH would only include
existing directories, and would want to be warned about missing ones.
I overlooked that MS Windows adds site-lisp directories without checking
they exist. Also there's no clean way to detect what a site-lisp
directory is in the EMACSLOADPATH case (simply checking for site-lisp in
the name is not robust).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]