I introduced '--ignore-file .project' to `projectile-git-fd-args` in
4fcf332 expecting fd to ignore the file if it didn't exist, but it
throws an error if it doesn't, causing it to throw these errors in any
project without a .project file.
Amend: 4fcf332749
Reverts projectile-project-root-files-bottom-up to its original value,
since the absence of those VC entries may surprise folks who aren't new
to projectile.
I intend to eventually replace projectile with project.el, so these
doom-projectile-* variables need to be generalized, starting with the
fd/ripgrep executable paths.
ALong with that, this refactors Doom's projectile-generic-command to
lean more on built-in fd support in projectile, where possible (fewer
wheels reinvented).
Ref: doomemacs/core#1
I intend to keep `project-vc-extra-root-markers` much lighter than what
`projectile-project-root-files` ended up being, so I won't be
transferring all the root markers.
Ref: doomemacs/core#1
BREAKING CHANGE: This deprecates the IS-(MAC|WINDOWS|LINUX|BSD) family
of global constants in favor of a native `featurep` check:
IS-MAC -> (featurep :system 'macos)
IS-WINDOWS -> (featurep :system 'windows)
IS-LINUX -> (featurep :system 'linux)
IS-BSD -> (featurep :system 'bsd)
The constants will stick around until the v3 release so folks can still
use it -- and there are still some modules that use it, but I'll phase
those uses out gradually.
Fix: #7479
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
Since fd 8.3.0 has low availability across distros (see repology link
below), I don't want to make it Doom's minimum supported version.
Instead, I do a quick version check and adjust accordingly. I'll think
up a more elegant solution after v3.
Ref: https://repology.org/project/fd-find/versionsFix: #6618Fix: #6600Close: #6597
BREAKING CHANGE: This restructures the project in preparation for Doom
to be split into two repos. Users that have reconfigured Doom's CLI
stand a good chance of seeing breakage, especially if they've referred
to any core-* feature, e.g.
(after! core-cli-ci ...)
To fix it, simply s/core-/doom-/, i.e.
(after! doom-cli-ci ...)
What this commit specifically changes is:
- Renames all core features from core-* to doom-*
- Moves core/core-* -> lisp/doom-*
- Moves core/autoloads/* -> lisp/lib/*
- Moves core/templates -> templates/
Ref: #4273
