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
Allow ahead-of-time native-compilation during CLI operations that
install or update packages. This will not retroactively native-compile
already-installed packages, you'll need to use --rebuild to do so.
(This is a stop-gap solution until the v3.0 release)
Fix: #6811
When running `doom sync --rebuild` after emacs upgrade the user is
prompted with "Installed packages must be rebuilt. Do so now?", even
though doom was explicitly instructed to rebuild. This PR removes this
prompt when the `--rebuild` option is provided
Showing `user-init-file` in the startup message seems more confusing
than helpful, especially to beginners, as it's not a file they can (or
should) be editing to fix whatever caused the error. Plus, its value
could be `t` if the error happens late enough in the startup process,
which is even less helpful.
Before this, text that extended past the new line's length would
persist, causing garbled output like this:
> Ensuring packages are installed and built...
> Updating recipe repos...
> Cloning org-appear...r emacsmirror-mirror...
- No packages need attention
Which might lead you to believe org-appear is being cloned from
emacsmirror-mirror, but the full output is actually:
> Ensuring packages are installed and built...
> Updating recipe repos...
> Updating recipes for melpa...
> Updating recipes for nongnu-elpa...
> Updating recipes for gnu-elpa-mirror...
> Updating recipes for el-get...
> Updating recipes for emacsmirror-mirror...
> Cloning org-appear...
- No packages need attention
The motivations for delaying the site-lisp files are different between
interactive and non-interactive sessions. I've revised these comments to
reflect that.
This advice is intended to fake the death of buffers that are visible in
other windows, and prevent Emacs from switching to a non-real buffer
after it's killed/buried. It shouldn't even try to do any of this if
`kill-buffer-query-functions` fails, even if it is a fake death.
Wrap doom-customize-theme-hook and use that wrapper also when the local
doom--customize-themes-h-* hook is called immediately, otherwise
settings will be written to custom-file, which is what I've been trying
to avoid with all these takes!
Amend: 0b13525252
Ref: #7929Close: #7933
Co-authored-by: real-or-random <real-or-random@users.noreply.github.com>
Setting custom--inhibit-theme-enable to t isn't enough, since
custom--should-apply-setting will return non-nil if THEME is 'user.
Ref: #7929
Amend: 68771150ba
`custom-theme-set-faces!` calls `custom-theme-set-faces`, which will
mark the customizations for saving to custom.el. But
`custom-theme-set-faces!` is not intended for permanent customizations.
I fix this by setting `custom--inhibit-theme-enable` to prevent some of
the extra work `custom-theme-set-faces` does around changing faces, and
call face-spec-set manually.
Also renames doom--custome-theme-set-face to doom--normalize-face-space,
to better reflect what it does.
Close: #7929
Co-authored-by: real-or-random <real-or-random@users.noreply.github.com>
SPC is equivalent to y when y-or-n-p prompts you, which seems way too
easy to hit by accident, especially with our leader key being (or
involving) SPC by default.
Doom inserts some expensive hooks in MODE-local-vars-hook, like
triggering LSP servers, tree-sitter, or visual enhancements -- things
that are unnecessary in temporary (invisible) buffers, so I suppress
them altogether there.
Toward our eventual goal of moving smartparens out of core, I've adapted
this from code provided by hpfr on Discord, which was adapted from
smartparen's syntax-ppss caching logic. `:config default` will need need
some attention before we can fully move smartparens to its own `:editor
smartparens` module.
Co-authored-by: hpfr <hpfr@users.noreply.github.com>
This one was sneaky. `doom-plist-merge` was mutating the second plist
fed to it, causing issues upwind of its uses. In #7925, for example,
calling `doom-package-recipe` to read a package's recipe would end up
altering it, copying sub-properties of :recipe to other packages'
recipes.
If you've hit #7925, you'll also need to delete your build-cache to get
around the error. I.e.
rm -f $EMACSDIR/.local/straight/build-*-cache.el
doom sync # or upgrade
Fix: #7925
If DIR is not a project and does not have root markers, create a
transient project instead. This ensures that `project-find-file-in`, and
by extension vertico, is still used in non-project directories instead
of falling back to `find-file`
Ref: 1b0af3bfc7
Calling (doom-adjust-font-size 1) repeatedly would keep increase the
font size because an increment is passed.
When loading themes, the doom-big-font-mode minor mode gets loaded again
therefore it causes the font to get increased.
Fix: #7845
BREAKING CHANGE: This removes the pcre2el package, which Doom was using
solely for one function to escape PCREs. In the interest of thinning out
Doom's core, I've hoisted a simpler version of the function into Doom's
stdlib so I can remove the dependency.
The -!/--force flags suppress straight's 'how to proceed' prompts, but
not the secondary ones like 'Really delete remote "origin"?'. This fixes
that.
Fix: #7906
To make these errors more consistent with similar commands/operations,
as well as rely less on cl-check-type (cl-lib's understanding of the
`font` type is a bit odd; they'd emit warnings/errors about this, but
still perform the checks -- I opted to check more explicitly instead).
BREAKING CHANGE: This removes git-gutter as an implementation for the
`:ui vc-gutter` module, leaving only the diff-hl implementation. There
are no longer any +git-gutter or +diff-hl flags for this module. Users
don't have to do anything to keep the vc gutter, unless they prefer
git-gutter for any reason (in which case they'll need to install and set
it up themselves).
This has been planned for some time, because of a roadmap goal for Doom
to lean into native/built-in functionality where it's equal or better
than the third party alternatives. diff-hl relies on the built-in vc.el
library instead of talking to git directly (thus expanding support to
whatever VCS's vc.el supports, and not git alone), which also means it
can take advantage of its caching and other user configuration for
vc.el. Overall, it is faster and lighter.
What I've also been waiting for was a stage-hunk command, similar to
git-gutter:stage-hunk, which arrived in dgutov/diff-hl@a0560551cd and
dgutov/diff-hl@133538973b, and have evolved since.
Ref: dgutov/diff-hl@a0560551cd
Ref: dgutov/diff-hl@133538973b
Ref: https://github.com/orgs/doomemacs/projects/5/views/1?pane=issue&itemId=58747789
* lisp/lib/autoloads.el(doom-autoloads--scan) Remove invoke
`file-truename` of file, keeping symbolic from being converted to a real
path.
* lisp/doom-modules.el(doom-module-from-path) Replace
`file-in-directory-p` with `string-match` to determine the module to
which the file belongs.
Fix: #7821
