bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#10208: site-lisp directories in load-path after --no-site-lisp


From: ASSI
Subject: bug#10208: site-lisp directories in load-path after --no-site-lisp
Date: Thu, 12 Jan 2012 11:38:42 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

Am 11.01.2012 02:08, schrieb Glenn Morris:
Thanks for tracking this down, I installed something similar.

Appreciated, however I can't check right now.

I had not appreciated half of what init_lread does, nor that
installation-directory is actually nil in installed Emacs (and would be
better named "build-directory" IMO).

Yes, this whole business of naming and using these variables might require something of an overhaul.

AFAICS, there are still the following issues:

i) EMACSLOADPATH overrides --no-site-lisp; it probably should not.

I haven't given this one much thought so far; but again, the general scheme might be in need of re-evaluation.

ii) This presumably means --no-site-lisp does not work in --with-ns
builds, since they set load-path via EMACSLOADPATH (IMO, it's a bug that
one part of Emacs uses an env-var just to communicate with another, see eg
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6401#48 )

These could both be solved by simply removing any Vload_path element
matching "site-lisp" near the end of init_lread. (I guess this would
remove the need for the MS Windows build to implement this feature
separately as well.)

I don't have a build environment set up on Windows, so I can't comment here.

This would still leave:

iii) Any --enable-locallisppath element that does not happen to have
"site-lisp" in its name will not get removed (but such elements already
mess things up because they will break the sorting of load-path that
init_lread tries to do).


Perhaps it would be better to split PATH_LOADSEARCH in epaths.h into a
default and site-lisp component, and simply not add the latter with
--no-site-lisp.

I'd be in favor of having separate path variables. The two searchpath components are already seperately available in make during the build, so it may not be even that difficult. However, such a change might need to be postponed to the next release of Emacs.

Finally, I noticed that you have some changes installed (for Org) that
are not marked as "tiny changes", yet you don't seem to have a copyright
assignment. IF you have not completed one, are you willing to do so?
The process is straightforward.

I had sent you a mail last year regarding this, I'll send it again. Please let me know if you don't get it.


--
Achim.

(on the road :-)





reply via email to

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