fix: defer projectile's project cleanup

There are two issues here.

1. Projectile uses file-remote-p to check for remote (tramp) paths in
   its known project list, when it automatically cleans it up on
   projectile-mode's activation. This causes tramp.el to be loaded,
   which is expensive.
2. file-remote-p relies on an entry in file-name-handler-alist
   (autoloaded by tramp.el) to detect remote paths, which causes tramp
   to be loaded. However, Doom sets file-name-handler-alist to nil at
   startup for a noteable boost in startup performance.

   Normally, this is not an issue, as I defer projectile-mode until well
   after file-name-handler-alist is restored, but it is trivial for a
   user to inadvertantly load it too early (often as part of another
   package that depends on it, or by blindly following projectile's
   install instructions and calling projectile-mode themselves).

In order to address both of these, I defer projectile's cleanup process
altogether. Another approach I considered was to ensure projectile-mode
wasn't activated until the right time, regardless of when projectile is
loaded, but this may trouble savvier Emacs users who need projectile's
API early during startup, so it needs more consideration.

Fix: #6552
Ref: bbatsov/projectile#1649
This commit is contained in:
Henrik Lissner 2022-09-06 20:24:55 +02:00
parent 7e65329289
commit 42ac62df74
No known key found for this signature in database
GPG Key ID: B60957CA074D39A3

View File

@ -44,13 +44,19 @@ debian, and derivatives). On most it's 'fd'.")
(global-set-key [remap find-tag] #'projectile-find-tag)
:config
(projectile-mode +1)
;; Auto-discovery on `projectile-mode' is slow and premature. Let's defer it
;; until it's actually needed. Also clean up non-existing projects too!
;; HACK: Projectile cleans up the known projects list at startup. If this list
;; contains tramp paths, the `file-remote-p' calls will pull in tramp via
;; its `file-name-handler-alist' entry, which is expensive. Since Doom
;; already cleans up the project list on kill-emacs-hook, it's simplest to
;; inhibit this cleanup process at startup (see bbatsov/projectile#1649).
(letf! ((#'projectile--cleanup-known-projects #'ignore))
(projectile-mode +1))
;; HACK: Auto-discovery and cleanup on `projectile-mode' is slow and
;; premature. Let's try to defer it until it's needed.
(add-transient-hook! 'projectile-relevant-known-projects
(projectile-cleanup-known-projects)
(projectile-discover-projects-in-search-path))
(projectile--cleanup-known-projects)
(when projectile-auto-discover
(projectile-discover-projects-in-search-path)))
;; Projectile runs four functions to determine the root (in this order):
;;