Mildly related: I have found that the best text editor I've ever used is neovim with Claude code writing the config which I don't look at. I'm not a huge fan of 'vibe coding' or whatever, but being able to configure my editor in English is amazing.
eg.
"Make <leader>L run `lint/all` on the codebase"
"Make yanks use the system clipboard so I can y or p to the clipboard"
"Make it so <leader>yd yanks the current file name"
"Make it so <leader>yD yanks the current file name and path, eg. a/b/file.txt:30"
Plus with nvim 0.12, there's a native package manager, so I can just ask the agent to add a vim.pack.add() for whatever plugin I want.
eg. "Add telescope using vim.pack, and set up <leader>fg to to grep in the cwd"
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.
> Anybody knows how has the community split between Kakoune and Helix in the end?
The two communities are mostly distinct and don't share much of the same population. Kakoune is far more niche and intimate. My understanding is that it's too esoteric for most people to bother with, whereas Helix is usually a more direct transition from something like Neovim.
Kakoune is the most fun to play with IMO. It has great concepts to learn and a genuinely refreshing philosophy. But being too different is often a dealbreaker for people. Their mental model tends to be: "Okay, visual mode by default is nice, but Helix gives me that plus everything I already have in Neovim" (aside from deep customization).
Does any of them support more advanced functionality that can be provided with plugins? Similar to how, let's say, Emacs has slime for lisp?
From what I see helix has stopped being developed, probably ppl think its done but i feel its half baked without a plugin system and tons of basic functionality missing.
It’s easy to build from source though, I’ve been using it daily for over a year, and there already are several dozen reasonably sophisticated plugins available. You can browse a list of mine here: https://github.com/stars/waddie/lists/helix-plugins-steel-li...
I go either end of editor. The simple in Cot editor on Mac although I now run Linux so I had to develop my own version of cot editor for it as I missed it too much. If not that or on a low powered device I often go neovim.
Mildly related: I have found that the best text editor I've ever used is neovim with Claude code writing the config which I don't look at. I'm not a huge fan of 'vibe coding' or whatever, but being able to configure my editor in English is amazing.
eg. "Make <leader>L run `lint/all` on the codebase"
"Make yanks use the system clipboard so I can y or p to the clipboard"
"Make it so <leader>yd yanks the current file name"
"Make it so <leader>yD yanks the current file name and path, eg. a/b/file.txt:30"
Plus with nvim 0.12, there's a native package manager, so I can just ask the agent to add a vim.pack.add() for whatever plugin I want.
eg. "Add telescope using vim.pack, and set up <leader>fg to to grep in the cwd"
CC has been a godsend for tricky LSP setups in Emacs as well.
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.
The visual by default editing mode of Kakoune really made me like the vim way, where vim couldn’t. Im very glad for that.
I see the development of Kakoune is much more active than I thought it was. That’s heartwarming!
Anybody knows how has the community split between Kakoune and Helix in the end?
> Anybody knows how has the community split between Kakoune and Helix in the end?
The two communities are mostly distinct and don't share much of the same population. Kakoune is far more niche and intimate. My understanding is that it's too esoteric for most people to bother with, whereas Helix is usually a more direct transition from something like Neovim.
Kakoune is the most fun to play with IMO. It has great concepts to learn and a genuinely refreshing philosophy. But being too different is often a dealbreaker for people. Their mental model tends to be: "Okay, visual mode by default is nice, but Helix gives me that plus everything I already have in Neovim" (aside from deep customization).
Another similarish editor is Helix, which is, I think, nicer since it has tree sitter grammars builtin
Does any of them support more advanced functionality that can be provided with plugins? Similar to how, let's say, Emacs has slime for lisp?
From what I see helix has stopped being developed, probably ppl think its done but i feel its half baked without a plugin system and tons of basic functionality missing.
Helix is actively developed, they just haven’t cut a release since July last year. Most recent major feature to land in master was workspace trust.
The Scheme-based plugin system (https://github.com/mattwparas/helix/tree/steel-event-system) is almost ready to go. The plan is to merge it to master after the next release, whenever they get round to that.
It’s easy to build from source though, I’ve been using it daily for over a year, and there already are several dozen reasonably sophisticated plugins available. You can browse a list of mine here: https://github.com/stars/waddie/lists/helix-plugins-steel-li...
I searched a bit to find the extension language. Basically an embeddable Scheme similar to Racket in Rust.
https://github.com/mattwparas/steel
I go either end of editor. The simple in Cot editor on Mac although I now run Linux so I had to develop my own version of cot editor for it as I missed it too much. If not that or on a low powered device I often go neovim.