Have been using this instead of vim for a month now.

It's incredible. No messing with plugins and archaic config files. All works out of the box, including LSP integration. Highly customizable still. Extremely fast, too.

I love "space-k" (Show docs for item under cursor).

The one thing I'm still struggling with is the kakoune-like movements. Maybe I'm doing something wrong, but they do feel inferior to vim's.

I agree it's nice, but Helix's default LSP for Python is unusably slow, having used pyright with Vim/Emacs/VS Code. I tried setting up the pyright language server to work with Helix, but could not get it to work. It will be much more usable once there's better documentation.

what kind of motions are you missing? I prefer helix to default vim, but miss the power of the amazing lightspeed.nvim plugin.

There's been some prototyping on easymotion type jumps: https://github.com/helix-editor/helix/pull/1162

In Vim you can also hit Shift-k to open docs (I usually use it for manual pages).

In this case, space k will open a popup with docs/definitions provided by the language server.

Very intrigued, waiting for the wasm-plugins though.

There are a few plugins I cannot work without. It's nice they have tree-sitter and lsp out of the box, but I can't live with things like hop[0]

[0] https://github.com/phaazon/hop.nvim

I got curious about this and found https://github.com/danr/kakoune-easymotion which I'm going to give a try.

I haven't tried helix in a while, sometimes they have chosen not-quite default-kakoune like bindings which trips me up for certain kinds of selections.

It's a bit surprising how many easymotion style plugins (n)vim ecosystem has. I discover a new one every other week or so.

Helix is my daily driver and it's got such nice defaults I haven't even bothered configuring it.

For modern code editing it's just faster. Everything's built in natively.

I made two changes: switched my theme to everforest-dark and reduced scroll-lines from 3 to 1.

I was very happy to see that second option as it still hasn’t been implemented in neovim [0].

[0]: https://github.com/neovim/neovim/pull/12355

I use Kakoune very extensively. I've tried out Helix a bit though. While I'm adequately informed to make an assessment about Kakoune, my opinion about Helix is more impressionistic.

My overall assessment is that Helix has the potential to run away with the Kakoune interested crowd! For a new editor Helix looks shockingly polished!

Here is what I like:

- Tree sitter is integrated into Helix. Kakoune use a lot of regexes for syntax highlighting (except when the syntax highlighting can be done by the LSP). I really like that

- LSP is built into Helix so you don't need to worry about adding extra plugins. It just works! (Worth mentioning: Kakoune has amazing LSP integration via the separate kak-lsp plugin though)

- Helix is built in Rust. Kakoune is built in C++. I've encountered the occasional segfault in Kakoune and I would guess that these would be rarer in Helix simply because Rust makes it easy to write "safer" code by default

I find Kakoune as more minimalist and consistent in its editing philosophy. Helix AFAIK does not have a good plugin story yet. OTOH it is almost trivial to write a plugin in Kakoune.

Kakoune's pure-editing features (multiple cursors, selections and other primitives) seem richer and deeper. Helix has a wider selection of features "out of the box". As Kakoune has been around for a while it feels more mature. Helix is designed to be an "editor for all" and tries to be a bit like spacemacs with the spacebar as an important key. (BTW Kakoune has relegated the large spacebar key to a relatively minor functionality which is a pity).

Helix feels a bit more responsive and snappy than Kakoune on my machine. (But both are very fast). That could be because I was comparing vanilla Helix with Kakoune+plugins. However, long term, because Kakoune likes shelling out frequently, that might be a bottleneck on how responsive Kakoune will always ultimately be.

Helix seems to have a very fast pace of development. Kakoune moves much more slowly and ponderously. Kakoune's creator is quite hesitant about adding new features possibly in a desire to keep the core editor small and consistent. Kakoune also tends to be a bit opinionated about accepting features in general in its code-base.

Coming to the innards of Helix & Kakoune you can see the differences in the philosophy of both editors. The Helix code base liberally uses many rust crates to build the editor. Apart from a recent C++ compiler and a posix system Kakoune has literally _no_ dependencies -- not even ncurses or a regex library! Basically, Kakoune likes to build everything in-house. This approach has its benefits and pitfalls which I'm not going to debate here.

While Kakoune has had a lot of community contributions over the years, Helix seems to have lot of community momentum behind it currently.

> Helix is built in Rust. Kakoune is built in C++. I've encountered the occasional segfault in Kakoune and I would guess that these would be rarer in Helix simply because Rust makes it easy to write "safer" code by default

No segfaults, but Helix is definitely somewhat buggy at the moment, especially on Windows. Panics make it relatively easy to debug though.

Kakoune is gimped by the fact that Mawww had children and cannot dedicate nearly as much time to the project as they had planned to. The idea was to have monthly releases, but that quickly fell by the wayside.

Helix is interesting, and built in LSP and Treesitter is really cool, but it feels like it's missing some of the core principles of orthogonality that Kakoune has. It has the potential to overtake Kakoune very quickly simply due to how active its community is.

How did you get Kakoune to segfault?

Kakoune is built in C++. So bugs will sometimes manifest as segfaults. You could be doing some normal editing, press a sequence of editing commands that might trigger some code that may subtly wrong. Sometime later, when C++ code tries to write to memory that it shouldn't have, you will segfault.

In that respect this is true for any C/C++ application. Kakoune keeps fixing these issues as they come up.

> tries to write to memory that it shouldn’t have

To elaborate what I mean here is maybe the program tried to write to an address not mapped to its address space etc. This happens due to bugs in the program e.g. not calculating the offset into an array properly and so forth. There are many ways to mess up when using C/C++!

You can segfault in rust, too:

  fn totally_safe() -> i32 {
    unsafe { *std::ptr::null() }
  }

This commonly happens if the person who wrote 'totally safe' thinks what they're doing is fine, and it actually isn't.

wow, I pulled up a C++ file in Helix just now -- never used it before -- and the LSP just worked out of the box. Amazing. Setting up LSP is usually quite a pain in editors like this.

I gave it a try but I couldn’t figure out how to disable the editor help popups or hide the line numbers. For all the sane defaults, I’d miss the configurability of Vim.

The code is well organized, and compile times are short, so at least it’s hackable.