Oh, it's really cool, I like it a lot.
I often use it and micro in Docker and servers to replace vim (to be honest, I don't like vim, I find it difficult to use -- just my personal opinion), with x-cmd I can quickly use helix and micro, just x hx, x micro.
The first issue I ran into was wanting to learn a replacement for one of the only vim-fu’s I know, which is like ci’ to replace what’s inside single quotes on the current line. After getting help from the (super nice!) community the answer was too complex and I moved back to vim.
I imagine these types of problems generalize since everyone has their own little muscle memories and workflows. It’s hard to replace such an entrenched tool. I’m always rooting for the new underdog though.
To replace inside single quotes, you can do `mi'c`. There's nothing to restrict it to the current line, but you will see the selection before you hit c. That's the big benefit of the noun-verb model that Helix uses.
I'm kinda the opposite way, now. The normal mode in Helix feels great to me; you press space and get an annotated menu of keyboard shortcuts. Space + f drops you into a file search for the current directory. Space + w + h gives you a split, Space + w + w switches splits, and closing any one is a quick :q! away. To me it feels the closest I've seen a terminal editor get to that VS Code comfort of everything being at arm's reach. But it does take a bit of exploring to find the good parts; I also recommend micro to people that don't enjoy the modal editing lifestyle.
Helix is my daily driver. I love it! Kakoune's editing model, built in tree sitter and LSP, works great with zero config. My only gripes are I wish it had Kakoune's client-server model and collaborative editing.
I have a question for Helix users. Do you use multiple selections? Years ago I gave Helix a shot and found that many themes, including the default theme, don't differentiate between the primary and secondary selections. It turns out that's still the case:
Are you wondering about Kakoune vs Helix ? Here are some of my thoughts (I'll try to be objective):
I got into Kakoune long before I discovered Helix. I'm passionate about Kakoune and it still has the odd advantage over Helix but in 2024 someone new to modal editing (noun-verb style) is probably better off picking up Helix. In my case I stick to Kakoune because I guess I'm just used to it and I'm able to write one-off "kak scripts" aka plugins that help with my workflow. As far as I know writing plugins in Helix is still not possible / or still being figured out.
What Helix has going for it is is that it comes with built in tree sitter, LSP support and built in multiple screen support. The kak-lsp plugin provides that LSP support in Kakoune and is top-notch in case anyone was wondering. Many LSPs provide tree sitter based syntax coloring which kak-lsp supports which is a silver lining for Kakoune. (Kakoune lacks built in tree sitter support; some plugins try to provide tree sitter support. You need to use kakoune in somehing like tmux for multiple screen support).
In my occational use of Helix, I notice that it is very responsive and fast -- Kakoune is pretty fast too but Helix is better. It makes sense because Helix integrates LSP tightly which is a big part of what an editor does nowadays. Helix also has a slightly more attractive TUI and is much easier to use out-of-the box.
I wish Kakoune had the community momentum that Helix does. Helix has couple of other advantages: it is built in more a reasonable language (Rust) compared to Kakoune (C++) which allows using a lot of Rust's amazing libraries. This means that Helix can acquire new capabilties much more easily via awesome rust crates !
Kakoune BTW totally eschews any external dependency which is underappreciated. You just need clang++ / g++ to compile Kakoune. (P.S. Have you tried compiling neovim from source :-) ?!) When I setup a new VM, one of the first things I do is compile kakoune from source. Because of a lack of dependencies its trivial to do. Then I compile kak-lsp. Incidently the kak-lsp plugin is built in Rust so its also easy to compile also because cargo handles all the dependencies there too.
In conclusion, Kakoune's philosophy is to build an editor core that is small and polished and delegate everything else to plugins. Helix's philosophy is to have an editor with the important functionality all built in. Kakoune's development seems to have slowed down quite a bit over the years as it converges on a minimal featureset while Helix seems to keep accelerating. The creator of Kakoune does not have as much time as before to devote to the project it seems. The Kakoune project still receives regular updates, bug fixes and the occational minor feature of course (but nothing earth shattering in the years I've been following Kakoune).
There is strict control on what goes into Kakoune. The bar to getting anything in Kakoune is very high and very dependent on the tastes of the Kakoune creator. Looking at the breath of external contributions in Helix, I would guess that Helix is more accepting of external contributions and willing to be much more feature rich. Kakoune tries to be too minimalistic -- maybe too minimalistic for my personal taste. Some of this could be due to the lower current bandwidth of the kakoune maintainer rather than any inherent minimalism perhaps.
If I've confused you -- maybe that is a good thing. I would suggest trying out both Helix and the kakoune+kak-lsp combination. It's good to have many editors in your life. It gives you a wonderful perspective on how to do things: Kakoune is a breathtaking gem of innovation. Helix is all that remixed, polished and improved. But Kakoune still has a few tricks up it sleeve like extensibility.
That's not that kind of jump the OP is talking about. dumb-jump/anyjump are plugins which allow you to jump to definition / declaration etc. without having any kind of language server running or having preprocessed the source code. They work by essentially grepping through the source code on the fly with some language specific smartness on top to make it work better.
17 comments
[ 3.1 ms ] story [ 55.9 ms ] threadI imagine these types of problems generalize since everyone has their own little muscle memories and workflows. It’s hard to replace such an entrenched tool. I’m always rooting for the new underdog though.
Examples:
]f (next function)
]t (next type definition)
Alt-o (select rootward syntax tree node)
Alt-i (leafward node)
Alt-p (previous cousin node)
Alt-n (next cousin node)
https://github.com/helix-editor/helix/issues/3842
As a former Kakoune user it's hard to imagine using multiple selections effectively without that.
More often than I initially expected.
> many themes, including the default theme, don't differentiate between the primary and secondary selections.
Doesn’t really bother me, though I can see the usefulness.
I got into Kakoune long before I discovered Helix. I'm passionate about Kakoune and it still has the odd advantage over Helix but in 2024 someone new to modal editing (noun-verb style) is probably better off picking up Helix. In my case I stick to Kakoune because I guess I'm just used to it and I'm able to write one-off "kak scripts" aka plugins that help with my workflow. As far as I know writing plugins in Helix is still not possible / or still being figured out.
What Helix has going for it is is that it comes with built in tree sitter, LSP support and built in multiple screen support. The kak-lsp plugin provides that LSP support in Kakoune and is top-notch in case anyone was wondering. Many LSPs provide tree sitter based syntax coloring which kak-lsp supports which is a silver lining for Kakoune. (Kakoune lacks built in tree sitter support; some plugins try to provide tree sitter support. You need to use kakoune in somehing like tmux for multiple screen support).
In my occational use of Helix, I notice that it is very responsive and fast -- Kakoune is pretty fast too but Helix is better. It makes sense because Helix integrates LSP tightly which is a big part of what an editor does nowadays. Helix also has a slightly more attractive TUI and is much easier to use out-of-the box.
I wish Kakoune had the community momentum that Helix does. Helix has couple of other advantages: it is built in more a reasonable language (Rust) compared to Kakoune (C++) which allows using a lot of Rust's amazing libraries. This means that Helix can acquire new capabilties much more easily via awesome rust crates !
Kakoune BTW totally eschews any external dependency which is underappreciated. You just need clang++ / g++ to compile Kakoune. (P.S. Have you tried compiling neovim from source :-) ?!) When I setup a new VM, one of the first things I do is compile kakoune from source. Because of a lack of dependencies its trivial to do. Then I compile kak-lsp. Incidently the kak-lsp plugin is built in Rust so its also easy to compile also because cargo handles all the dependencies there too.
In conclusion, Kakoune's philosophy is to build an editor core that is small and polished and delegate everything else to plugins. Helix's philosophy is to have an editor with the important functionality all built in. Kakoune's development seems to have slowed down quite a bit over the years as it converges on a minimal featureset while Helix seems to keep accelerating. The creator of Kakoune does not have as much time as before to devote to the project it seems. The Kakoune project still receives regular updates, bug fixes and the occational minor feature of course (but nothing earth shattering in the years I've been following Kakoune).
There is strict control on what goes into Kakoune. The bar to getting anything in Kakoune is very high and very dependent on the tastes of the Kakoune creator. Looking at the breath of external contributions in Helix, I would guess that Helix is more accepting of external contributions and willing to be much more feature rich. Kakoune tries to be too minimalistic -- maybe too minimalistic for my personal taste. Some of this could be due to the lower current bandwidth of the kakoune maintainer rather than any inherent minimalism perhaps.
If I've confused you -- maybe that is a good thing. I would suggest trying out both Helix and the kakoune+kak-lsp combination. It's good to have many editors in your life. It gives you a wonderful perspective on how to do things: Kakoune is a breathtaking gem of innovation. Helix is all that remixed, polished and improved. But Kakoune still has a few tricks up it sleeve like extensibility.
- lack of global search (like ripgrep integration) and something like dumb-jump/anyjump — it's faster and less resource-intensive than running LSP
- I encountered a couple of panics losing my unsaved changes after 24.03 update, most recently yesterday. Looks related to this bug: https://github.com/helix-editor/helix/issues/3501
I can live with no global search, but not with data loss. Probably will stop using it for now.
<space> + /
Maybe it's kind of niche feature, but that's how I navigate my code, and that's what would work even greater with helix performance.
They added jumps about 6 months ago: https://github.com/helix-editor/helix/pull/8875
I haven't experienced data loss, but I agree that's a blocker for regular use.
That's not that kind of jump the OP is talking about. dumb-jump/anyjump are plugins which allow you to jump to definition / declaration etc. without having any kind of language server running or having preprocessed the source code. They work by essentially grepping through the source code on the fly with some language specific smartness on top to make it work better.