Reverse load-path to fix precedence issues

Originally, I built the load-path with site-lisp paths first, then
packages. There was a modest ~10% startup boost doing this, because
there were considerably more site packages loaded at startup than
plugins.

However, this meant built-in packages would get precedence over plugins,
which is undesirable. In org's case, I simply modified the load-path
in lang/org/init.el. However, this issue has cropped up again in #340.

Evidently, that 10% boost may not be worth the risk it imposes, so I've
rearranged the load-path with packages first.
This commit is contained in:
Henrik Lissner 2018-01-10 22:42:22 -05:00
parent 669b3cbbb0
commit 2b98e550e8
No known key found for this signature in database
GPG Key ID: 5F6C0EA160557395
2 changed files with 1 additions and 12 deletions

View File

@ -169,7 +169,7 @@ startup."
;; Also, in some edge cases involving package initialization during a
;; non-interactive session, `package-initialize' fails to fill `load-path'.
(setq doom--package-load-path (directory-files package-user-dir t "^[^.]" t)
load-path (append doom--base-load-path doom--package-load-path))))
load-path (append doom--package-load-path doom--base-load-path))))
(defun doom-initialize-autoloads ()
"Ensures that `doom-autoload-file' exists and is loaded. Otherwise run

View File

@ -1,11 +0,0 @@
;;; lang/org/init.el -*- lexical-binding: t; -*-
;; Ensure ELPA org is prioritized above built-in org.
(eval-and-compile
(when-let* ((old-path (locate-library "org" nil doom--base-load-path)))
(setq old-path (substring (file-name-directory old-path) 0 -1))
(delete old-path load-path)
;; We remove it from the base load path too so that `doom//reload-load-path'
;; won't undo this modification.
(delete old-path doom--base-load-path)))