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

[Robert Weiner <rsw@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

On Mon, Aug 1, 2016 at 1:19 PM, Alex Dunn <dunn.alex@gmail.com> 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
​
​

[-- Attachment #2: Type: text/html, Size: 4510 bytes --]