Re: why is site-lisp placed before the default load path?

[Alex Dunn]

OK.  I'm still not convinced this is good default behavior, but I'll defer to y'all.  Realgud solved the issue in their case by adding .nosearch files in the subdirectories, which I didn't realize was an available tool.

On Mon, Aug 1, 2016 at 10:54 AM, Robert Weiner <address@hidden> wrote:

On Mon, Aug 1, 2016 at 1:19 PM, Alex Dunn <address@hidden> wrote:

But there are plenty of other ways to do that.   This makes it a little too easy to override important core libraries, IMO.  

​It should be easy for a site or a user to override default behavior in Emacs.  Sometimes this means having modifications loaded prior to particular local initialization files running and changing load-path.

​

 

realgud is just an example.  It uses names like js.el and info.el because they are supposed to be loaded via `load-relative`, rather than required directly, but subdirs.el placing them at the front of the load path is what's causing trouble.

​Given all the existing tools that look for Elisp files by filename, find-library being just one, it is not a good assumption that the filename will always be uniquely identified by adding a directory name.

  Rocky could add 'realgud-' to the beginning of every elisp file in the application,

​That would be much better and safer and more generally useful.

​

 

but `load-relative` and the directory structure makes that unnecessary.

You might argue that every elisp file in an application should be named to avoid conflicts with core libraries, but the only reason I see for that requirement is the current ordering of the load path.

​There are others.

​

 

And beyond the inconvenience caused by programs using `load-relative`, or programs just accidentally using the same name as a core library, it seems possible that a malicious developer could tuck their own `url.el` into an otherwise innocuous package and cause some mayhem.

​Yes, Emacs is a pretty open environment that relies on a lot of trust among users and developers.  The community helps keep bad actors from acting badly.  Emacs has existed for decades without a major issue like you describe and there are very likely good reasons for that.

​Bob

​

​