I spent a while trying Kakoune years ago and I have one minor complaint and one major complaint. Leading off with the minor complaint (because it’s more annoying than severe): it is designed for multiple cursors editing as the default, rather than single. That is, many of the normal movement operations (such as search) have the side effect of leaving behind extra cursors, like little breadcrumbs, that take an extra keystroke to dismiss.
Perhaps this makes sense for people who spend all day doing large-scale edits on highly structured files but it makes no sense for the kind of everyday editing that I do. Most of my time is spent either entering brand new text in bulk at the end of the file, or jumping around and making one-off changes via searching. When I want to do larger scale edits (I use vim, the editor kak was intended to succeed), I reach for :%s///gc to do confirmation-based global substitutions (or sometimes :g//s///gc instead of %s).
So I really don’t see the advantage of the multiple cursors approach, especially given that the files I’m working with are thousands of lines long. That is far too long to get any visual feedback benefit to using multiple cursors for whole-file substitutions.
Now on to the major complaint. For some reason, the developers decided to buck the trend of plugin-based editors by not including a built-in scripting language with a nice API. Instead, people wanting to extend Kakoune are expected to write bash scripts (!?).
Sorry, this is a colossal mistake that dooms the editor to irrelevance for the foreseeable future. They would have been far better off just picking a nice scripting language (how about Python, Ruby, or Lua) and building a really clean, sensible API for it. Bonus points for building in a package manager that can browse, fetch, install, and update plugins automatically. This is the one massive area of weakness for vim (VimScript? Ugh!) and they missed the boat!
Kakoune is scripted over IPC, not bash scripts. The configuration language has some built in functionality for embedding bash scripts, and for smaller plugins or one-off personal customization, yeah you can do everything in a bash script.
But absolutely nothing forces you to implementing plugins as shell scripts! kak-lsp, which provides great integration with language servers, is written in rust. Peneira, a fuzzy finder tool, is implemented in python. People have written libraries for various languages that make interfacing with kakoune from your language of choice quite convenient.
The decision to make all extension functionality work over IPC instead of an embedded scripting language means everything that the editor is capable of can be controlled by any piece of software over a thoughtfully crafted and well-documented interface. Also the extensions people write for kakoune end up also serving as general purpose utilities that can be integrated into stuff other than kakoune.
I've always considered kakoune's approach to extensibility the main selling point of the editor. It has quite phenomenal plugin support for such a niche editor, and it's way easier to make your own plugin than it is with other editors because of how streamline the API is.
> That is, many of the normal movement operations (such as search) have the side effect of leaving behind extra cursors, like little breadcrumbs, that take an extra keystroke to dismiss.
Uh, no? Unless you’re talking about undo which can indeed be annoying in that way when undoing a multicursor edit.
In particular, search with / and its modified versions does not change the number of cursors, and neither does the next occurrence command, n. You have to explicitly say N (that is <s-n>) to add a new selection at the next occurrence rather than move the current one there, or use s and friends which are specifically geared to act on each match within the current selection(s).
Are you sure you aren’t pressing something you shouldn’t be out of (Vim) habit?
Perhaps it’s changed since the last time I used it, but I do strongly recall it adding multiple cursors with regular n. Those cursors might not have been “live” for editing, but they were still there to distract me.
That's probably because you confused Vim and Kakoune key bindings.
Kakoune
- n: next match
- alt+n: previous match
- shift+movement: extend selection by movement
Vim
- n: next
- shift+N: previous match
So if you press shift+N as you are used from vim, you start adding a lot of selections instead of going to previous match. I believe this difference is the most confusing for people who switch from Vim to Kakoune.
Nothing I can find about that in the changelog, but it’s possible. (Side note: “Development version: <a-u> and <a-U> now undo selection history.” Finally.)
My normal workflow these days is select first match with /, then N to accept match and continue to the next one or n to reject and continue; then edit all at once. (For me, the principal advantage of this over standard find-and-replace is that the edit doesn’t need to be restricted to the inside of the occurrence—for a bulk code edit, I often can’t quickly write a regexp for what I need to modify but can write one for something predictably close to it.)
Now that I’m thinking about it, your preferred workflow of confirming each replacement separately can be replicated like this for literals: use / to select first match, then Q, c, enter replacement, <esc>, Q. Then n to go to second match, q if you want to replace, n for third match, etc. (Here Q starts then ends recording a keyboard macro, q plays it back.) More complex replacements and regexp groups will be trickier but possible. (E.g. for s/whatever/before&after/ set up the replacement with /, whatever, <enter>, Q, i, before, <esc>, a, after, <esc>, Q.)
And now I’ve changed my mind on keyboard macros which I had thought were a silly feature for Kakoune. Hah.
As an alternative to gc you can page through selections with parens and alt-space to dismiss individual selections.
its also easier to compose filters, eg matching all lines that contain regex A and B regardless of order. doing that with vim regex is kind of annoying and it gets programming worse the more filters you need to add
Also its not bash specifically. You can send kak commands to the kak session from any programming language. As an example kak-lsp is in rust
As an alternative to gc you can page through selections with parens and alt-space to dismiss individual selections.
And that’s great, it means kakoune is capable of accomplishing the same task via an equivalent multiple-cursors trick.
But it’s not the way my mind works. It forces me to go through and prune the set of cursors before I start making the substitution. I don’t want to do that! I want to write the text of the substitution first (for the common case) and then y or n to yay/nay each substitution because often I don’t know (and don’t want to think about) everything my search pattern matched.
its also easier to compose filters, eg matching all lines that contain regex A and B regardless of order
I can count on one hand the number of times I really needed to do that in the two decades I’ve been using vim.
This is really the crux of the issue with Kakoune. It takes the good enough philosophy of vim’s composable count-motion-commands and tries to achieve apotheosis with a visual-motion-multiple-cursors scheme. In search of the perfect tool to let an octopus to edit the file everywhere at once, it leaves us humans behind. It also ignores the lessons of “Worse is Better” [1] in pursuit of philosophical purity.
One massive thing you lose with multiple cursors versus macros is you lose the ability to perform the same action across multiple files. Like you said, some multi cursor stuff is more useful to developers more focused on large-scale rewrites and refactors. However I argue macros are even more useful, because they can be saved and replayed across many files (even globally and automatically with just a few commands).
Perhaps this makes sense for people who spend all day doing large-scale edits on highly structured files but it makes no sense for the kind of everyday editing that I do. Most of my time is spent either entering brand new text in bulk at the end of the file, or jumping around and making one-off changes via searching. When I want to do larger scale edits (I use vim, the editor kak was intended to succeed), I reach for :%s///gc to do confirmation-based global substitutions (or sometimes :g//s///gc instead of %s).
So I really don’t see the advantage of the multiple cursors approach, especially given that the files I’m working with are thousands of lines long. That is far too long to get any visual feedback benefit to using multiple cursors for whole-file substitutions.
Now on to the major complaint. For some reason, the developers decided to buck the trend of plugin-based editors by not including a built-in scripting language with a nice API. Instead, people wanting to extend Kakoune are expected to write bash scripts (!?).
Sorry, this is a colossal mistake that dooms the editor to irrelevance for the foreseeable future. They would have been far better off just picking a nice scripting language (how about Python, Ruby, or Lua) and building a really clean, sensible API for it. Bonus points for building in a package manager that can browse, fetch, install, and update plugins automatically. This is the one massive area of weakness for vim (VimScript? Ugh!) and they missed the boat!