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.
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
Although it is rare for a user to not enable the :config default module,
enabling/disabling modules one-by-one is common practice for debugging
Doom Emacs. This PR fixes an error that occurs when you have :completion
vertico enabled without enabling :config default.
This is the only internal usage of :bind, which I want to avoid, because
it pulls in bind-key, which offers no real benefit over just about any
other key binding function or macro, so I'd rather use what is already
available (like map!).
The tramp string used to connect to the container uses the first
`container-runtime ps` argument as a username, but the first argument
returned is the container ID, not a username.
Close: #7674
Co-authored-by: bergmannf <bergmannf@users.noreply.github.com>
Co-authored-by: elken <elken@users.noreply.github.com>
This removes the old `&` separator for Vertico (does anyone use that
instead of just space?) in favor of escapable space and unifies
orderless config with Corfu. Also implements smart separator
insert/escape/reset on `C-SPC`
Co-authored-by: Liam Hupfer <liam@hpfr.net>
* feat(vertico): completion highlights a la ivy
Adds completion highlighting that works similarly to ivy/counsel's
one (which is enabled by default). It'll highlight enabled major/minor
modes and directories in a different face. On by default.
Ref: https://github.com/minad/vertico/wiki#candidate-display-transformations-custom-candidate-highlighting
* fix(vertico): major mode not being highlighted
The major mode was not being highlighted correctly;
it should work now that the buffer is set correctly in
`+vertico-highlight-enabled-mode`.
* fix(vertico): make font lock prioritize match over type
The mode and directory highlights were [overriding the match
font-lock](https://github.com/doomemacs/doomemacs/pull/7706#issuecomment-1977722188).
This should resolve that by prioritizing the match font lock using
`'append` on `add-face-text-property` instead of `propertize`.
We should always bind to both "TAB" and "<tab>" - if they have been
mapped to different commands anywhere, Emacs will no longer treat them
as equivalent.
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
Currently, fd does not expose a way to match against only the path
components beneath the target path. When --full-path is specified, the
pattern matches against all components. For example, executing
consult-fd from /home/hlissner/.emacs.d with `home` as the query would
match every file (not excluded by other arguments) under .emacs.d.
Despite this --full-path behavior, fd still outputs relative paths, so
the user cannot even determine why some candidates are returned.
Until there is a method to match only against subdirectories, use
--absolute-path to at least to show the user why all matches are
occurring.
Ref: https://github.com/sharkdp/fd/issues/839
We were using `shell-quote-argument`, which is meant for passing file
names, strings and so on, not command-line arguments. For example,
`(shell-quote-argument "--foo=bar")` yields "--foo\\=bar", which is
obviiously invalid unless we're trying to pass an option named '--foo\'.
At any rate, there is no quoting/escaping for shells in the default
value of `consult-ripgrep-args`, so it doesn't look like this is
something we need to do.
