They are currently set to
<leader> a. The motivation for this is as follows:
Least intrusive key-chord type binding I could find. Doesn’t interfere with other keybindings for the most part (unlike
C-owhich clashes for in minibuffer
evil-want-minibufferusers and regular buffer evil users), with the exception of:
C-;is bound to
flyspell-auto-correct-previous-word. via the built in flyspell map.
C-;is bound to
+company/completein the vanilla emacs bindings.
We could also just bind it in the minibuffer if we do end up going with the leader key.
Still has some overlaps, but perhaps less important:
org-cycle-agenda-fileshas redundancy in
It is however less convenient than
Even though top level module dependant bindings are frowned upon, here is my case for why this should be an exception:
- It provide a useful shortcut for a bunch of commands relevant to the symbol at
point, and seems to be better at this than built in stuff, e.g. doing
<leader> f Dto delete a file in
eshelldoesn’t work, but embark recognises that it’s a file, so
<leader> a ddoes.
- other than helping with discoverability for stuff this also allows for
commands for things that are too niche for top level bindings, such as actions
package!statements and recipes or urls.
- vertico is slated to become the default completion module, which makes this
less of an inconsistency, but I’m not sure about the performance slowdown in
map!since that seems to be one of the main concerns.
embarklike most packages in the vertico cinematic universe can be installed independently, so if you find it sufficiently useful you could also have a stripped down version of the config in doom core that is just used for on-buffer actions.
- It provide a useful shortcut for a bunch of commands relevant to the symbol at point, and seems to be better at this than built in stuff, e.g. doing
We also might want to add keybindings for
SPC s sand
SPC s S
There isn’t really a vertico/consult analogue to
consult-isearchdoes something else (give you previously used isearch search terms). Bound to
consult-linethis opens a
occur-editbuffer, which is a more natural fit but breaks slightly from the
Do we want to have the annotations be more like ivy? e.g.
- Have a project column in the buffer annotations and a relative path? This has
some overlap with project narrowing
SPC b B p SPC.
- Mark the modified/remote status of the buffer with color, on top of the modification column?
- Change colors in general?
- Have a project column in the buffer annotations and a relative path? This has some overlap with project narrowing
!style dispatcher is only as a prefix, due to the abundance of
!final macros. In my opinion this is useful enough to break consistency.
Completion Style on file paths
Currently we have the following completion style override for files:
(setq completion-category-overrides '((file (styles . (orderless partial-completion)))))
This means that
parital-completionmatches (basically completing word prefixes + globbing) only get considered if there are no
orderlessmatches. I find this to be the useful order, since I only really want
partial-completionfor the globbing, but it does mean that you lose the ability to type the first few letters of a file and only get the files that start with that, since you get broader orderless matching. Ivy doesn’t have this distinction with prescient on, but does seem to only show hidden files only after there are no visible ones left, which we don’t have here.
This also relates to the recommended settings in the vertico readme for remote hostname completion somewhat. It’s hard for me to figure out what’s best here because I don’t have any remotes to try this out on.
Initialisms by default
Do we want to use
orderless+initialismby default for some of the completion categories? see here.
Decide what Vertico extensions to use
Currently we only use
vertico-repeat. Do we want to use any other ones or leave that to users?
vertico-mousewould probably be good to have on by default, but something in doom is making it slow.
Decide what to do with
Company completion style
Currently we advise
company-capf--candidatesto try the default emacs completion styles before orderless, since trying orderless first leads to a bunch of junk candidates. We could let the company completion style here be a variable for mildly easy customization, and we could also use orderless but use a custom sorting function like
vertico-sort-length-alphawhich has decent results (see here).
consult-bufferis what the vertico module uses on
SPC b B.
What should be shown by default?
Currently it just uses the default settings of showing open buffers, recent files, and bookmarks by default. It’s possible to have it only show buffers by setting the recent files and bookmarks sources to be hidden, or pre-narrowing the command.
Org buffer source
I’ve added a consult source that lets you narrow for org-mode buffers. Originally I did this by autoloading
org-buffers-list, but beyond potential snappiness considerations regarding loading org too early, I would also occasionally get nondeterministic void variable errors on
org-buffers-list, which I suspect are caused by the use of
:defer-incrementallyin the org
This is currently implemented by only adding the buffer source in an
after! orgstatement, but per minad every additional buffer source slows
consult-bufferdown, so it is worth consideration if this option is desired at all. I haven’t noticed a difference, but it might be noticible on slower machines.
Even if the
ivymodule isn’t loaded, it’s packages can still get loaded by other means, such as
counsel. This means that the
fboundplogic in the definition of
+default/yank-pop) (and formerly in the definition of
doom-project-find-file) won’t work unless the vertico option is checked first, which is what we do for now.
Without the new
ui/workspaces/config.el), new projects don’t get opened in a new tab, but the exact working of this whole set up are a bit opaque to me.
Filtering for editing snippets with C-c & C-v leads to
user-error: Couldn’t find a snippet with uuid nil. Might be a continuation of this issue. Works with Ivy.
previewing buffers outside of the currently active workspace (e.g. with
consult-buffer) shouldn’t pollute the current workspace with buffers from other workspaces
Speed up async commands
SPC /is noticeably slower on vertico than on ivy.
The gimmies are lowering
consult-async-input-throttle, which are currently at the default settings. They can be lowered with no drawback for small projects, but this may cause issues on larger ones. I think there isn’t currently a way to set these per command, I’ll open an issue about that, seems like it should be a thing.
Better Marginalia annotations for Projectile commands (maybe upstream)
Fix the duplicate candidate issue
See here. If this doesn’t get fixed upstream by the time of the merge we should add an override for
Embark Export/Collect popup logic
Expand the popup logic to all export and collect buffers after henrik gets a better feel for the whole thing
Hide hidden files
Ivy didn’t show hidden files when filtering if there were visible matches left. I (Gauge) like that it shows hidden files right away, but some people on the discord miss this feature. Should there be a toggle?
Go over all the cool new embark stuff that have been happening in the past month and see if any of them are relevant to Doom
SPC n bis bound to a function, but
bibtex-actionsdoesn’t have a main dispatch function like
ivy-bibtex, rather it has a bunch of different ones. Binding the
bibtex-actions-mapthere would probably be better, but there are nontrivial loading order shenanigans happening that make that not straightforward.
SPC b bshould switch workspace after choosing a buffer from a different one
- Universal argument for opening buffer in another window?
[c] lookup module:
in all likelihood requires writing
What will it take to make him happy? Geez, tough customer.
What did my emojis do to you?
With Ivy, SPC i e worked exactly as expected, with
emojify-modeturning incomprehensible squares into nice little emojis. With Vertico though, I’m left with incomprehensible squares .