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).
vi basic grammar is verb followed by object; it’s nice because it matches well with the order we use in English, "delete word". On the other hand, it does not match well with the nature of what we express: There is only a handful of verbs in text editing (delete, yank, paste, insert… ), and they don’t compose, contrarily to objects which can be arbitrarily complex, and difficult to express. That means that errors are not handled well. If you express your object wrongly with a delete verb, the wrong text will get deleted, you will need to undo, and try again.
Kakoune’s grammar is object followed by verb, combined with instantaneous feedback, that means you always see the current object (In Kakoune we call that the selection) before you apply your change, which allows you to correct errors on the go.
Unfortunately, I'd rather see this as an alternative input mode in vim/vscode/nvim than separate editor, so I won't need to throw away all knowledge/plugins/dotfiles accumulated over time, than switching to completely new editor. Baggage is hard.
After having tried both, I prefer verb-object for editing operations any day. Especially since its more natural to add a number for repeating. And its excellent for macros.
I dig this too. It's what I loved about Quicksilver - it had simple grammar that went direct object, verb, (optionally) indirect object. That tied nicely into the plugin system, which gave it tremendous flexibility. Successors like Alfred, Google Bar and Raycast are trying to recreate the unix command line and it doesn't work nearly as well.
The first part of this https://karthinks.com/software/fifteen-ways-to-use-embark/ also talks about how inverting action and object can be useful, and how Emacs's embark package makes it possible to even go back and forth between object and action as needed.
I love the way he is basically modelling the way we interact with an editor as a grammar, or in mathematical terms. It's so interesting what kinds of designs you can come up with when you can successfully apply a different way of thinking about it.
People say this about data.method() vs function(data) and about PowerShell using Verb-Noun when they want Noun-Verb. It's pretty clearly either a personal preference, or a thing where different contexts read better one way or the other.
There are a lot of operations in vim that I don’t need or want to see the selection. Sometimes it would be useful, and if I think so, I use visual mode instead.
I tried using Kakoune as a daily driver for a while. I still bust it out now and then when there's something I want to do that would _really_ benefit from multiple cursors or structured regular expressions, but there's things that made me ditch it as my main editor:
1) Lack of windowing. I understand the pitch of radical simplicity by leaving this to the terminal editor, but it's just annoying as shit trying to write windowing configurations for different terminal editors. Something like making a window split and hopping between them shouldn't feel hacky and weird.
2) Extending the editor with Kakscript. Posix shell scripting is already something I do as little as possible, it's pretty much the worst programming language I can think of. Scripting kakoune uses shell scripting but it's far even worse, you descend into some weird un-debuggable eldritch horror mess of nested blocks of sh and eval mixing shell script semantics with kakoune editor state semantics.
Actually editing text with it feels amazing, though. It's like the yin to Emacs' yang.
I tried Helix maybe about 6 months ago. It was pretty good, but there were things I do regularly in vim that I couldn't do in Helix, and the obvious way to do it in Helix didn't work (but it did in Kakoune when I tried that).
I mentioned this on whatever chat was listed on Helix's website as the place to go, and everyone there was open to making the obvious thing work, so I'm guessing Helix will get there at some point, but I don't want to use it now. Certainly given the relative momentum of the two projects Helix should get there some day.
Helix is awesome but have been disappointed by the core devs stance toward integrating some form of copilot. It's really difficult to use an editor that doesn't support it at this point.
Yeah, that's basically the case. They don't have a plugin system, afaik it's still in the planning phase. They have LSP support, but copilot is a non-standard kind of LSP, and last time I looked the devs weren't interested in doing the integration work needed to get it all working nicely.
Can't say I blame them, it's their project after all. Just frustrating because I would totally use helix if not for the lack of that one feature. I actually still use it, but just as a quick way to make edits in the CLI, and not for full time dev. It's a great editor and project nonetheless.
Came to post this myself. What I love about Helix is that it just works out of the box. Install your toolchain and LSP and off you go. I absolutely do not want to have to write my own Vim config, or install some tool that configures a ton of stuff I don't understand.
> Mainly by having more things built-in. Kakoune is composable by design, relying on external tooling to manage splits and provide language server support. Helix instead chooses to integrate more. We also use tree-sitter for highlighting and code analysis.
I switched from Kakoune to Helix after using Kakoune for a few years. Helix, to me, is everything i loved about Kakoune but with better defaults. It being in a language i love also is fun, as i almost immediately forked it and changed a few things - handy when they're still figuring out plugins.
The site makes a surprisingly compelling pitch to me, a grumpy and set in his ways vim/Linux user.
But, I don’t know. It is hard to overcome the fact that vi clones have been around for a bazillion years, will almost certainly outlive all of us, and will always be in every repo.
> It is hard to overcome the fact that vi clones have been around for a bazillion years, will almost certainly outlive all of us, and will always be in every repo.
Vi's ubiquity & longevity are good reasons to learn vi as at least a backup.
But, I don't think it'd be worth limiting yourself to plugin-less, unimproved vi just because there are some circumstances you won't be able to use your personalised setup. -- Since you'll be using your own configuration 99% of the time, I don't see the above as all that relevant for using something like kakoune.
I don't usually feel the need to spread religious truths to the masses, but I'd be happy to know to that it was because of me that someone learned that the best vi(m) really is emacs in evil-mode.
This is the problem with moving off vi motions: you can get vi motions almost everywhere. Jetbrains, check, Visual Studio, check, vscode, check, sublime, check, firefox, check. The best I found for Kakoune (which I do significantly prefer) was an approximation of it for vscode, and nothing else.
Typically I use vim+tmux, so I should have also probably set up some additional extension to add a tmux-like panel change shortcut, so I could save-and-run like I normally would on the command line.
It also didn’t seem to handle Jupyter cells well. I forget exactly, but sometimes it would jump from one panel to another instead I think?
I have tried my hand at Helix, a Kakoune-derivative, but I'm immensely bothered by the selection re-drawing as I move around: it creates visual noise. When I move, I just want to move; when I act, I just want to act. The problem of "maybe I wanted to delete 4 rather than 5 words" tends to not come up often enough to demand a solution as common programming notational practice tends to establish very obvious boundaries, e.g. df= (delete to the assignment operator), dfP (delete to first capital P, where maybe I'm renaming a method getFilePath with my cursor on the character 't'), d$ (delete to end of line), etc
I love kakoune's client-server design. I can open multiple terminal windows instead of terminal splits and panes (which I can never remember the shortcuts).
My main gripe is the extension model. Plugins run in a separate process which interacts with the editor by printing kakoune commands to standard output. Marshalling data and proper string escaping is a pain. Not to mention that many plugins are in bash, because it's the minimum common denominator.
For those of you that use VS Code, there is a plugin[1] that follow a lot of the Kakoune grammar but doesn't try to emulate fully, opting instead for better integration with vscode. I have been using it for a few years after using Kakoune for a few and then trying and failing to make my own Kakoune emulation mode for vscode.
It is pretty much how I use the computer today, with few improvements with emacs and tmux. As I am teaching my daughter how to use cat/cut/grep etc, I am doing so truly thinking that this is the best way to use a computer in 2023.
The other day I was teaching her few shortcuts ^P and so on, I thought that maybe its time to re-think this whole cursor and keybinds thing. With apples vr magic goggles maybe someone can make an editor that I can follow code and write text and have 50 chats with some llm discussing various parts of the code I am working on.
All editors are limited by monitor space, the linux kernel style guide still has 80 column recommendation (not a hard limit since 2020), the way we jump into and out of code, or we step into thing, all are very limited and are pretty much the same since 1984.
I hope soon we have tooling like in the Hackers movie (https://www.imdb.com/title/tt0113243/) and use our eyes more to be able to follow code and systems.
The complexity of the systems has increased (e.g. cloud, hundreds of services, even LSP, tons and tons of boilerplate and generated code), but our tools are stuck.
I primarily used Kakoune for 2 months a few years ago. I loved its featureful regex engine which made certain macros much MUCH easier to write than Emacs functions. I also loved the selection-first editing model and have reimplemented that in Emacs and VS Code. But Kakoune was far too basic for me to get much serious C++ work done. You have to use external TUIs and CLIs constantly, and obviously those all have no integration with your Kakoune configuration.
Kakoune has some good ideas, eg. piping commands into it and having the editor immediately execute them is a really good one. Reminiscent of acme for Plan9, which exposes virtual files for its buffers and to receive commands, which makes it really convenient to develop tools for it.
That all being said, Kakoune simply doesn't offer enough for me to use it over vim. One of the first things I always see presented is multi-line-editing, a feature that could, maybe, come in handy once or twice a month for me. Comparing that to the simple fact that vim matured for over 30 years, and the sheer size of it's ecosystem, and switching to another modal terminal based editor is a really hard sell.
The object-verb syntax is a not a selling point to me, because I can have the exact same "preview" effect by using a vim plugin like easymotion:
d<leader><leader>w
and I can see exactly to where it will delete before any changes happen to the buffer.
is there a thing like rlwrap or "kakkeys" for zsh (or in the browser like vimium)? i use kak as my main editor, but i don't like to mentally switch to vi keys for anything else every time.
the problem with all these hipster vims is that it's too late in the game, vi is everywhere you're going to be remoting into and these are only going to be on your localhost, not even off a fresh install. your muscle memory might as well carry over, same reason evil mode is the only modal extension for emacs that matters and QWERTY is the only keyboard layout for sane people
That massively depends on how often you remote into machines. It's also the same logic for using bash instead of zsh, a battle that zsh is winning - it turns out that learning one does not prevent learning both.
With recent integration of Copilot Chat in vscode, I’m less inclined to use Neovim or any terminal based editor. I think terminals had a time and place, but it’s time we moved on to tools that are more user friendly and provide better features.
This is far beyond just an opinion about text editors. The terminal isn't going anywhere. It's the fallback, or sometimes the only, interactive mode available. Many developers use both vscode and vim on a daily basis, including myself. I see them as the best editors in their respective environments.
I've been using the vim vscode plugin in vscode-nightly with Copilot Chat for a few weeks. I'm far from a vim expert, but I think you don't understand the point of vim, which is perhaps best understood as a language for text manipulation. Also, I have not found the chat feature of Copilot to be particularly useful.
TUI vs GUI seems orthogonal here, there are Copilot plugins for Neovim. Microsoft deciding what capabilities to make exclusive to its editor GUI is just vendor lock-in, not a fundamental refutation of the paradigm of modal TUI editors.
> I think terminals had a time and place, but it’s time we moved on to tools that are more user friendly and provide better features.
The terminal is not an impediment to "better features", and "user friendliness" is purely a subjective matter.
I find VSCode deeply unfriendly to my preferred method of editing code, and I imagine VSCode users find vim, kakoune, and emacs similarly unfriendly to their preferred method of editing code. Nobody is wrong in their findings -- what one finds unfriendly is objectively true to them.
But to say that I find VSCode deeply unfriendly is it not the same as your implying that terminals preclude "better" features and user friendliness. I'm simply recognizing preference, while what what you're saying seems to discount my (and that of many others) preference.
Even more hindsight on Vim, Helix and Kakoune - https://news.ycombinator.com/item?id=36427267 - June 2023 (3 comments)