Tried it again few days ago. I kinda get that currently you can only use AI on Helix through LSP, but on top of that it does not have auto-refreshing files when changed outside - makes it really hard to work with external AIs, as I'm just constantly worrying if I'm editing a stale file.

This has been my main editor for prose and code for a few years now (Sublime Text -> Atom -> Vim -> Helix). Overall, it has been great. Many LSPs work almost out-of-the-box, and my config is a fraction the size of my old .vimrc.

Surprisingly, it didn’t take that long to update my Vim muscle memory. Days or weeks, maybe? However, I still have mixed feelings about modal editors in general, and most of my gripes with Helix are actually about modal editors and/or console editors in general.

Code folding is a feature I’m still waiting for.

I love it but the search and replace sequences are too complicated and then I have no idea how to unselect multiple lines without specifying a line.

My vim muscle memory is too strong and stubborn.

Vim is like C, Helix is like C++ and Ki Editor is like Rust.

"Within C++, there is a much smaller and cleaner language struggling to get out."

Helix carries a baggage of ideas from Vim. It does not have consistent and transferable keybinds. It does not have composition of ideas:

You can move to the next line in the buffer editor with `k` but to move down to the next line in the file explorer you have to do `ctrl+n`?

Vim is like C, Helix is like C++ and Ki Editor is like Rust.

I learned about kakoune from helix. I played with both of them to figure out which one I preferred and ended up choosing kakoune for simplicity. It’s a fantastic editor and my cfg is 50 LoC which is just fine for me.

As long as helix doesn’t add a plugin system I think both are superior to neovim. Neovim defaults are just awful. I hate that quickfix and loclist are so close to being useful for pickers but it just misses the mark and now there’s lock in on some terrible impl because we don’t want to break backwards compatibility. The select -> action model is superior.

Having an opinionated editor just makes so much sense. We don’t need 10 different picker implementations.

Using agents to edit code. And Helix doesn’t support live update of files. This is the reason it’s not my first choice.

Do have a look at the second question in the FAQ :).

I do find Helix very impressive. I remember the Python LSP working without any configuration whatsoever.

However, I have vim muscle memory built over 25 years of use. I already struggle switching between Emacs and vim (or its equivalents) - for example, after a period of vim usage, I would press ESC repeatedly in Emacs, three of which are enough close a window. While Helix borrows modal editing from vim, it introduces subtle (and meaningful - I have to admit) variations, which unfortunately wreaks havoc with my muscle memory. Maybe the worst part about muscle memory is that unlearning is almost impossible. My dilemma, not Helix's fault...

I really wanted to like Helix, it's a great software, works out of the box. I dedicated energy to unlearn my vim habits and learn the helix way. I'm now able to use it fairly effectively, but eventually I just came to the conclusion the bindings are done the way they are due to simpler implementation, not simpler user interface. I'm back to neovim for small updates and zed in vim mode for larger code editing.

My default editor for the past couple years. Love the simplicity, speed, and the fact I can navigate comfortably with just the keyboard. Plus Elixir LSP integration is a cherry on top.

Helix has been my main editor for a few years now. I went from Sublime Text to VS Code to Neovim, and eventually landed on Helix. I’ve shipped a lot of code with it, and my config is still under 50 lines, even with a few extra keybindings to emulate some Vim bindings I still find useful. I didn’t find the keybindings particularly hard to get used to, and switching back and forth between Vim and Helix has never been much of an issue when I’ve had to work on a system without `hx`.

For the curious: https://github.com/seg6/dotfiles/blob/1281626127dfbf584c2939...

I want to like it, it's much snappier than vim, but:

I hate selecting lines up. Down xxx is fine. But to go up I have to do x alt; v k. This would be shift+v k in vim.

I often use } { to navigate the file in vim. In hx it's ] p which is very awkward for the fingers. The auto selection makes it hard to read once I use ] p.

Pasting does not behave like vim, often have to click o first then p.

I have to often press ; to unselect just to be able to insert after I navigate to a character with F f t T.

Can't copy from documentation. Can't create files in the explorer.

It feels like much more work to use hx keybindings than vim.

What I love:

Hints whenever you press a key allow you to learn keybinds quickly.

Very quick.

Built in search, file picker, lsp rust out of the box.

I wrote my own modal-mode extension for vscode/cursor because couldn't get the VIM-ones to function like I wanted. During that time, I thought that I should look into Kakoune and Helix as those seemed to represent a true iteration on the paradigm. Being able to see what you're about to change makes complete sense, as does the "multi-cursor first" approach.

However, after a few weeks, I ended up rewriting things to be more classic VIM-like after all. This might have just been muscle memory refusing to yield, I am not sure. One thing I remember though, was that the multi-cursor+selection approach only really helps when you can see everything you're about to change on the screen. For large edits, most selections will be out of the scroll window and not really helping.

I still haven't written it off completely, though with AI I increasingly find myself writing more prose than keywords and brackets, so I am not sure it's going to feel worth it.

Helix is a really nice editor. I use it as my go-to for when I'm in the terminal environment.

For sufficiently complex manipulations, I find the "selection-action" ("motion-action") to be more intuitive than "action-motion". Even with vim, I'd often like making use of visual mode.

I think the main limitation to this that I believe is it's probably a bit slower for quick + frequent edits compared to vim.

Worth noting: the plugin system is steadily approaching maturity and will probably be integrated and released soonish™ https://github.com/helix-editor/helix/pull/8675

I was really hoping this would have a postmodernist aesthetic

I want an editor that's built around language entities.

"Move to end of the scope" or "insert after this expression" and similar.

The overlap between languages should be large enough to make this feasible.

Love `hx`, vim never really clicked for me and the batteries-included nature of helix is one of its best selling points.

I desperately wish Helix would support virtual text (code folder, markdown links just showing the text when not selected), but the default keybinds and the way that selecting and editing text work just works too well in my brain to go anywhere else

Up voting, only because it is another native option, away from Atom started trend to ship Chrome alongside every single "modern" application.

Love the FAQ

  > Post-modern?!

  It's a joke. If Neovim is the modern Vim, then Helix is post-modern.

  > Is it any good?

  Yes.

A new version should arrive this month or the next one. I think it’s worth trying it again then

I haven't opened a text editor to code in months and probably won't need to anymore. Goodbye vim and intellij, nice knowing you. It was a good while it lasted. Glad I haven't invested decades into emacs like some of my colleagues.

I tried using it once by compiling it from sources. Even a release build is several hundred megabytes in size, which I find pretty wasteful. After a little investigation I found, that it has many plugins in form of a shared library, and each of them has pretty huge size, presumably because the whole Rust standard library is statically linked.