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

[Glenn Morris]

Achim Gratz wrote:

> The whole incantation that removes the site-lisp from load-path is
> safeguarded with "if (!NILP (Vinstallation_directory))", so for the
> installed Emacs the --no-site-lisp option is never actually acted upon,
> since installation-directory is nil.

Thanks for tracking this down, I installed something similar.
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).

AFAICS, there are still the following issues:

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

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.)

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.


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.