Helix vs Kakoune

Currently, i’m using Kakoune with some installed plugs such as kak-lsp. I see there is an alternative Helix which has taken all the ideas from Kakoune but adapts them to be more usable for coding. And it has written in Rust, i don’t know if it’s a better choice than C++.

I would like to understand what kind of potential both editors have, i mean if i stay with Kakoune and pay decent time to customize it(that’s not intuitive at the very beginning) how long can i be satisfied of the editor as a programmer who works on the big codebases, what a contribution can i bring to it while i’m not a C++ dev.

And vice versa, Helix already more adapted to coding and probably more productive from a start. But i don’t see there a community to contribute to. Here i’m not a Rust dev either.

A quick repo research shows that both editors are mostly developing by the owners:

Kakoune(301 contributors)

Helix(295 contributors)

Kakoune is more mature definitely.

In short, could you share your opinion about the conceptual differences and a potential both editors have? Now i’m struggling with customization and poor insertion mode keymap.
I like Kakoune anyway, it took me away from Vim.

2 Likes

I haven’t actually used Helix myself, but from what I’ve read about it, the Helix authors really care about making a polished experience - built in TreeSitter support, built-in LSP support, system clipboard integration, plugins implemented as WASM binaries with a well-defined API, etc.

Kakoune takes very much the opposite approach - none of those features are built-in, and the “plugin API” is basically “write shell-scripts to generate Kakoune commands”. There are third-party plugins for TreeSitter support, LSP support, system clipboard integration, etc. but they’ll never be as polished and solid as the equivalent features in Helix.

The upside of Kakoune’s approach is that if there’s some feature you want that Kakoune doesn’t yet support, it’s easy to write your own plugin that’s at least as robust as any of the built-in ones. They’re all pretty short and standalone, so you can just copy one and hack it up, but if you want to start from scratch that’s pretty easy too. Sure, it might not be the most polished or reliable implementation in the world, but neither are any of the other plugins — and if it breaks, you’ll be able to fix it yourself.

If you look at the Wikipedia article about “Worse is Better”, you’ll see lists of characteristics of “the New Jersey style” versus “the MIT approach”. I think Helix is an “MIT approach” tool, while Kakoune leans hard into the New Jersey style. Neither is “right” or “wrong”, but each of them delight some people and infuriate others. If you’re an “MIT approach” kind of person, maybe go check out Helix (or NeoVim, or VSCode, or a JetBrains IDE). If the New Jersey style is more your thing, check out Kakoune (or vis, or Plan 9’s sam or acme).

8 Likes

I got it. The main conceptual difference is west coast vs east coast. Thank you!

Personally I’ve barely customised kakoune at all. I don’t use it like an IDE. I did give helix a go to see if it could replace VSCode+Dance(a kakoune emulation plugin) as a batteries included editor for me but the project is too unpolished and has too many differences in key bindings to kak for me to feel comfortable with it.

To me the appeal of kakoune is it’s the best text manipulation tool I’ve ever used while also being quite simple to use. It’s scripting design makes it easy to hack together a good enough working environment for most problems. I guess the “worse is better” philosophy screwtappelo mentioned is relevant here.

Currently I think it’s much harder to just cludge something together in Helix. That might change.

I’ve written plenty of code in kak so it’s not like I think it’s an insufficient tool for that purpose. My main reason for not wanting to make my setup more complicated is the debugging experience when things don’t work is pretty awful. If you’ve experienced similar you might want to consider swapping. I doubt it’s actually any better in Helix but atleast the developers will be trying to make it unnecessary.

IMO it all depends on how many features you want that exist outside of Kakoune’s model.

helix relies too much on builtin functionality. its much harder to truly customize it.

the project is too unpolished and has too many differences in key bindings
What do you mean unpolished and what the key bindings made you uncomfortable?

About bindings in kak, for me personally they are a thing i just have to get used to. I don’t expect from any other editor key bindings be familiar, at the same time default ke ymap has matter.

Ok, what didn’t you find to customize Helix and what are hardships you had during customization, share it pls?

I meant unpolished in comparison to VSCode(+Dance). VS requires basically zero configuration and everything just works, that wasn’t my experience with Helix.

Helix uses modes, like vi, rather than modifiers like kakoune. In kakoune you use shift to extend, in helix you use v for visual mode. In kakoune you have <a-i> and <a-a> in helix you have mi and ma. The Helix approach might be better, but if you’re familiar with something else it’s another thing to learn.

AFAIK the only customisation you can really do in Helix atm is change keybindings. There’s more planned but if it’s implemented it’s not documented.

I can answer that.

I tried to use a different color for the background when in insert mode, so I can tell immediately which mode I am in (many times I forget to see the status line). If you want to do that in Helix, you must recompile the source, which might be easy to do, but you have to download all dependencies (which I do not want to do). In kakoune, this action was easy-peasy.

1 Like

One thing I love about kakoune is how it keep its core minimal, and yet provides some very handy features that are indeed easy to miss, the fuzzy candidates for regex select/search is god sent and also very consistent, I work in a big company and do 100% of my work in kakoune, kakoune feels to me like a unix skills multiplier with the face of a text editor, the more you know about linux, bash, etc… it will just make your productivity in kakoune explode, I like the extension approach kakoune took, it just resonates with my philosophy and the philosophy of many more, but each one of us should pick what gave us more joy.

8 Likes

Huh, I’ve never used fuzzy candidates for regex prompts :slight_smile:

Helix seems like an amazing project. Several recent kak-lsp improvements were stolen from inspired by Helix. Probably kak-lsp should also enable more features by default.

1 Like

I’ve figured out recently kak-lsp doesn’t rename objects in the modules they are imported from even if those modules are open in buffers. Isn’t it wierd? One of the most valuable feature…

It would be better if you text a few technical specifics instead of loud, general words. Thx.

He did, with the completion on regex example.

Here is another obvious one (but not easy to change afterward in a project that didn’t make this choice at the beginning) : a client-server architecture.

2 Likes

I’ve figured out recently kak-lsp doesn’t rename objects in the modules they are imported from even if those modules are open in buffers. Isn’t it wierd? One of the most valuable feature…

Technically, it works for me.
To reproduce, I opened foo.rs and bar.rs where foo.rs imports type Bar from bar.rs. With foo.rs as active buffer, I used lsp-rename on Bar. It renames Bar in both buffers.

Now there is a gotcha: bar.rs is not saved automatically (needs a manual :wa). This has surprised me many times in the past.
So I think we should save those buffers automatically (except maybe the buffers that were already dirty before the rename?). Will fix, thanks for pointing that out.

Back on topic: today Kakoune has enough features to support almost any use case people have thrown at it. At the same time, it’s still fairly simple; most of Kakoune’s interfaces are obvious and minimal. The small and stable core gives a lot of freedom (and work) to users and plugin writers.

Helix currently doesn’t have features like user-defined commands, hooks or a plugin API. This means that if you need a feature that is not supported by Helix core / LSP / treesitter you’d need to edit Helix’ Rust sources. I’m sure Helix will get runtime configuration features eventually - but so far they’ve focused on the out-of-the-box experience.

I think Kakoune is better suited to be a general-purpose computing environment because it is a frontend for a Unix system. Almost all my time reading/writing/discussing code is spent in Kakoune.
It’s very easy to hack up a “plugin” for everyday text-processing tasks. For example when viewing a (git) diff in Kakoune, we can hit Enter to jump to the corresponding source line. The implementation of this feature required little knowledge of Kakoune. It’s a bit more effort (at least when not used to Rust) to implement the same in Helix.
Helix is a frontend for nontrivial “code intelligence” tools tree-sitter and LSP which is a great help for many programming tasks.

3 Likes

should be fixed now in latest kak-lsp

I’m also new to kakoune, maybe a week

Before that, I don’t know too much about vim or other modal text editors, only know wq, d , 1,$d, and only occasionally use it to edit configuration files it the server.

This week, I finally had time to learn a command line text editor as my main editor, and I also don’t know much about bash, although I use bash a lot, but only for common commands.

I also tried helix, but I finally chose Kakoune.

The reasons for my choice are:

  1. Kakoune’s Unix combination philosophy
  2. consistent and intuitive design
  3. a friendly community (I’ve been asking a lot of newbie questions on GitHub issues lately, they taught me a lot, not only kakoune but bash)
  4. as far as I know, kakoune does not have any external dependency code, but helix depends on many many libraries, so if there is a problem in the upstream, you have to wait for the upstream to fix it or implement it, I have so much frustration about this.

In the long run, kakoune must be easier to maintain than helix, because it is designed to do one thing and to do it with pure Unix style. Helix’s philosophy is more like an IDE that wants the user to get started out of the box. I’m looking forward to its development, but at this stage, I don’t think it’s suitable as the main editor, but Kakoune has all the capabilities to be the main editor.

I have to say that when I first started learning Kakoune, I had some frustrating moments, mainly because I didn’t have much knowledge of either bash or vim, and I’m also not a native English speaker (I miss some docs sometimes), so it was a bit painful at first.

But during this week of learning, I really learned a lot about bash, because the core of kakoune’s extension is bash scripting.

Now, I’m not too happy with the current kakoune buffers plugins(I can only find two buffer plugins): Delapouite/kakoune-buffers, kakoune-buffer-switcher

So I’m writing my own now, fully functional plugin based on kakoune-buffer-switcher

In the process of writing, you will feel the consistency of its design and how happy you are to write the plug-in.

Another thing I’m not happy about kakoune is that I don’t find a proper way to hot reload plugins, now I have to save it, kill kakoune, and reopen kakoune to apply the new change.

TRAMPOLINE is the very nice tutor, but it seems you don’t have a convenient way to access it. I think it’s really helpful for beginer, Helix has a :tutor command for this, this is why I learn helix first …

My two cents, thanks!

2 Likes

Helix feels much less well thought out than kakoune. Kakoune has a solid philosophy that it adheres to, and the keybindings are (mostly) really consistent. Helix took kakoune’s selection first approach, but it did not take the orthogonality and consistency.

Kak has a pretty clean codebase with minimal (zero?) dependencies. Helix has an enormous codebase that is full of overengineering. For example, Helix uses rope science from the now-defunct Xi editor for its buffer manipulation, while Kakoune just uses a vector of strings. Despite rope science being “faster”, it doesn’t provide any noticeable performance benefit for most situations.

Helix will use WASM for its plugin API, once the plugin API actually exists. That is far more complex than simply writing a shell script, or calling whatever utility (whether or not it is compiled) you want from a shell script. While kak’s method is far from perfect - I would really like to have a proper IPC protocol using the session socket - it is extremely intuitive and plenty good enough for most things you want to do with it.

I have tried Helix several times, but it feels like it took inspiration from kakoune without really understanding the thought behind kak’s design. It feels much more like vim than kak, and not in a good way.

2 Likes

Hot reloading can’t be a general feature because plugins can do arbitrary things that might not be suitable for reloading. However for your own config it’s easy.

Thanks, I have tried this way, I set a shortcut for run selection:

It works for half of the cases. if I write a plugin, it can be a little annoying, but anyway, it’s acceptable.