Kind of a coincidence to see this post here, just after I’ve gotten done playing with Kakoune and poking around the docs.

After using Helix fulltime for two years, I’m considering a switch. Helix is fantastic OOTB and I have considerable muscle memory in it, but the pace of development is glacial. There are I think three active maintainers, and they’re completely swamped by PRs, many of which have sat unreviewed since they were openend. It’s enough to wonder why anyone would even consider contributing. That would be understandable if it weren’t for the fact that, no, Helix isn’t ‘finished’. Newer LSP features aren’t supported; DAP for python has never worked; I also miss code folding, bread crumbs, and tab name disambiguation. The steel scheme plugin branch is functional and several neat plugins are beginning to emerge. However, I switched back to main after noticing that the plugin branch adds about 1s to startup time. (I’m constantly opening and closing helix.)

Anyway, Kakoune has an attractive philosophy. There’s ‘editor for life’ potential. A really minimal core that I can shape to my needs in the moment. The scripting language looks even gnarlier than vimscript but no matter – we have coding agents for that now.

But Kakoune’s minimalism also brings downsides that make me wonder if it’s more effort than it’s worth. For example, that minimalism rules out a dependency on treesitter. But you can hardly expect to shell out for treesitter highlighting and expect good performance. With Helix, nvim, and Zed all consolidating on treesitter, I don’t see why I’d want to spend time on an already solved problem.

All in all, neovim is feeling like a better option, and as another commenter says, configuring it has become remarkably easy thanks to coding agents. And apparently native multiple cursors are on the roadmap.

https://sr.ht/~hadronized/kak-tree-sitter/ exists. I have not used it personally but the author has been pretty active and we had multiple discussions around performance, AFAIU it does not rely that much on the shell as most communication with Kakoune can take place directly over fifos.

Similarly https://github.com/kakoune-lsp/kakoune-lsp exists and has been a pretty good showcase of how complex plugins can be implemented in other languages than shell (rust here) with the extension model.

I am of course pretty biased, but I am regularly surprised by how simple/quickly things can be done with Kakoune's shell based model, and I its a part of the design I am pretty happy about in retrospect.

> I switched back to main after noticing that the plugin branch adds about 1s to startup time

Very curious what’s happening there. With empty helix.scm/init.scm, there is essentially zero measurable impact on startup for me.

Bytecode caching isn’t yet enabled (it is in progress), so I can see that kind of delay if I’m giving it tens of thousands of lines of code to evaluate on startup, but it took a lot of effort to get there.