This is due to `counsel-projectile-switch-project` not initializing the
known projects list before consulting the `projectile-known-projects`
variable (or at the very least, calling the function of the same name,
rather than referencing the variable directly). By changing
counsel-projectile-remove-current-project, it now does.
After setting +corfu-want-minibuffer-completion to t, I noticed that it
Corfu was still being enabled in Consult when finding files. This change
fixes that by ensuring that Corfu gets disabled in the minibuffer
whenever another completion framework is active.
In the interest of slimming down Doom's core (as we near v3), I've
deprecated these macros. They doesn't really need to exist. Sure, the
alternatives aren't as ergonomic or elegant, but they're good enough
that we don't need these trivial wrappers. Their local uses have been
refactored out as well.
consult-man is not a good drop-in replacement for man. consult-man
searches man pages and descriptions (like the apropos program).
The original man function lets the user pick a man page from the list of
man pages.
BREAKING CHANGE: This backports some architectural choices from v3.0.
This changes Doom's module API, renaming some functions and removing
others, in order to facilitate some new features, prepare to move Doom's
modules into separate repos, and make way for two, much larger breaking
commits coming in the next few days.
This commit won't break anything for users unless they're tinkering with
Doom's internals/using its `doom-module-*` API directly. I am avoiding
broader backwards incompatibilities until the 3.0 release.
What's new:
- Negated flags. (modulep! :editor evil -everywhere) will return non-nil
if :editor evil is active without its +everywhere flag.
- `modulep!` now takes multiple flags to simplify AND checks. E.g.
(and (modulep! +foo)
(modulep! +bar)
(not (modulep! +baz)))
Can now be expressed with:
(modulep! +foo +bar -baz)
- Adds pcase matchers for `doom-module-context` and `doom-module`
structs, making the following destructuring binds possible:
(pcase-dolist ((doom-module group name flags features)
(hash-table-values doom-modules))
...)
This will be used more in v3.0.
- Adds file cookie support to module init.el and config.el files.
Here's a summary of breaking changes made in this commit:
- `doom-module-context` was changed from a vector to a struct (record).
- `doom-modules` is now a table of `doom-module` structs, rather than
free-form plists.
- The following macros have been renamed:
- `doom-context-with` -> `with-doom-context`
- `doom-module-context-with` -> `with-doom-module`
- The followings functions have been replaced/removed:
- `doom-module-context`+`doom-module-context-get` -> `doom-module`
- `doom-module-set` -> `doom-module--put`
- `doom-module-p` -> `doom-module-active-p`
- `doom-module-context-key` (is now a getter with the same name)
- `doom-module-put` (removed)
- `doom-module--context-field` (removed)
- The signatures for these functions have changed:
- `doom-module-get CATEGORY &optional MODULE PROP` ->
`doom-module-get (GROUP . MODULE) &optional PROP`
- `doom-module-locate-path CATEGORY &optional MODULE FILE` ->
`doom-module-locate-path (GROUP . MODULE) &optional FILE`
- `doom-module-expand-path CATEGORY MODULE &optional FILE` ->
`doom-module-expand-path (GROUP . MODULE) &optional FILE`
- Adds the following functions
- `doom-module-exists-p`
- `doom-module-key`
- `doom-module->context`
- `doom-module<-context`
- Removes the following variables
- `doom-module--empty-context`
This commit results in a little redundancy, which I will address in
parts 2/3 and/or v3.0.
These optional dotfiles indicate the root of a module or module
group (:lang), and will later contain module metadata. They will also
serve as an alternative to packages.el and doctor.el, and will aide the
parts of the v3.0 module API concerned with resolving the current module
from a path (`doom-module-from-path`), which currently rely too heavily
on parsing path strings.
For now, however, they're simply placeholders.
Any buffers opened before company-mode was loaded would not have
`company-backends` initialized in them.
Fix: #6261Fix: #6180Fix: #5896Fix: #5672Fix: #2015
As mentioned in #7977, `global-corfu-modes` overrides any predicate
function in `global-corfu-minibuffer`. This is a stopgap until the issue
is resolved upstream.
Fix: #7977Close: #8039
Co-authored-by: LemonBreezes <LemonBreezes@users.noreply.github.com>
BREAKING CHANGE: This moves helpful.el out of core into :lang
emacs-lisp. Since most (all) people have this module enabled, this
shouldn't make a difference for most people, but if you're one of the
few that don't have :lang emacs-lisp enabled, Doom will revert to using
Emacs' built-in help.el and describe-* commands.
Others can also disable helpful with (package! helpful :disable t) if
they prefer Emacs' built-in help system, which wasn't possible before,
because it was a core package.
This was done as part of an ongoing effort to slim down Doom's core in
preparation for v3.
In vim/evil, C-n/C-p invokes dabbrev, so we're doing the same, but
powered by cape-dabbrev, falling back to corfu-next/corfu-prev is a
corfu popup is already open.
Close: #7748
Co-authored-by: 45mg <45mg@users.noreply.github.com>
Co-authored-by: LemonBreezes <LemonBreezes@users.noreply.github.com>
The original implementation of `+vertico-orderless-dispatch` match
pattern by prefix and suffix in pairs. In that case, '=&&' will go for
branch `(string-suffix-p "&" pattern)`, not `(string-prefix-p "="
pattern)`, which fail to filter literal '&&'.
We probably should match all prefixes first, then all suffixes. Just
like orderless does.
Ref: 178b0c55f2/orderless.el (L159)
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
Corfu effectively replaces Company. It's lighter, faster (in most
cases), and relies on more functionality native to Emacs (CAPF). The
company module is one of the more higher-maintenance (and buggy) modules
in our library, so rather than maintain two spiritually identical
modules, I'd rather focus on the better one.
I won't make any moves to actually remove the Company module until well
after the v3 release, when `doom sync` and `doom upgrade` have rollback
functionality, and those commands are better equipped to warn uses about
module deprecations (and we have our new Github Discussions board set
up, so we have a centralized place to announce them).
Ivy is practically Vertico's spiritual successor, and its module is one
of the more higher-maintenance modules in our library. Rather than
maintain two spiritually identicaly modules, I'd rather focus on the
better one.
I won't make any moves to actually remove the Ivy module until well
after the v3 release, when `doom sync` and `doom upgrade` have rollback
functionality, and those commands are better equipped to warn uses about
module deprecations (and we have our new Github Discussions board set
up, so we have a centralized place to announce them).
