Helix vs Kakoune

Help
8

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.

1 Like
9

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.

2 Likes
10

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.

11 Likes
11

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
12

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…

13

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

14

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
15

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
16

should be fixed now in latest kak-lsp

1 Like
17

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!

4 Likes
18

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.

4 Likes
19

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.

20

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.

21

you can just make the plugin reloadable/idempotent and source it manually with source path/to/plugin/the-plugin.kak

22

:joy: it makes sense!
I can do it, thanks very much!

23

I guess I’ll throw in my 2 cents. I tried Helix and I didn’t like how I couldn’t customize it much. I also don’t particularly like how the plugin API will use Web Assembly. Feels like overkill and kind of silly to use Web Assembly for plugins for you non-web editor application, but maybe that’s just me.

If there’s one thing that Helix has that I wish Kakoune had was builtin tree-sitter integration. It seems to be a more efficient way of parsing syntax trees and highlighting syntax in an editor, but tree-sitter is an external dependency and requires it’s own dependencies, so integrating it into Kakoune would go against what Kakoune offers: minimal dependencies (pretty sure ncurses is one of the few dependencies, if not they only), minimal defaults and no large API for plugins, just an interface to the POSIX shell.

2 Likes
24

I think my post addresses that which you where asking about, sorry it was not indexed for you, anyhow, I surely did forgot to speak about helix, I think despite being more “user friendly” out of the box, it is a less penetrable editor for programmers, as the concepts you need to know to extend/customize are far more specific than lets say regular expressions and shell scripting, while tree sitter is way more efficient than regexes, it drifts away from the domain of a more “general knowledge”, when I got to kakoune, I just had to understand the way it was extended, and after I understood the api of the editor I was set to do wathever I wanted, with helix otoh, I couldn’t and I wouldn’t be able to do it at the start as I don’t know a thing about tree-sitter or wasm (for when the plugin system is finally done), it would be an interesting experience to learn this, but my point is that despite kakoune differing from helix on the out of the box experience focus, I think generally speaking kakoune will feel more like home. I think Helix has some very nice colorschemes tho… I second all @raiguard said btw.

25

I think it does not uses ncurses anymore :V

1 Like
26

@krobelus Thanks for your continued iteration on this! I noticed the feature not working as expected months ago and chalked it up to either our project’s bizarre loader system, or having expectations too high for a solo project.

I recently updated and was alerted to the improvement by seeing an unexpected dirty file in my git :laughing:

1 Like
27

We highly appreciate users reporting issues / complain if something doesn’t work like in other editors.
I had also hit this problem with lsp-rename repeatedly but never realized that the behavior was wrong. (I coped with it by running :wa after lsp-rename :frowning:)