Discussion

Helix

Curiositry: 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. Code folding is a feature I’m still waiting for.

canistel: 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...

lorenzohess: Have you tried Emacs' Extensible Vi Layer ("Evil" mode)? My muscle memory switched almost seamlessly from Vim to Emacs with Evil mode

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

dilawar: I have been using an ergonomics keyboard for a while and find it impossible to go back to normal keyboard.For the last two weeks, I was forced to work at a normal keyboard. After initial pain for one day, I got back to typing at normal speed. Without losing my comfort with the ergonomic one. I can now just context switch. It wasn't easy though.Perhaps you will also become comfortable with both vim and helix after the initial struggle?

nurettin: 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.

kristiandupont: 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.

eviks: > only really helps when you can see everything you're about to change on the screenWhich is still a net positive over the alternative?

bayesianbot: 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.

small_scombrus: I know it's not a proper fix, but helix does have `:reload` and `:reload-all` commandsI have reload-all bound to Ctrl-r

postepowanieadm: Larry Wall vibes.

Panzerschrek: 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.

whytevuhuni: Interesting, although I checked and on NixOS the binary is just 29MB. It was statically linked, with just libc left as dynamic.I think 29MB is still huge for a terminal text editor, but nevertheless not "hundreds".Maybe you used "cargo build" without "--release", which adds a lot of debug symbols to it?

vaylian: > you can only use AI on Helix through LSPHow do other editors do this, if they don't use LSPs? Helix specifically choses LSP as the integration mechanism (in addition to TreeSitter) for supporting different programming languages, because it is a language-agnostic protocol and therefore only needs to be implemented once. Is there some established AI-agnostic protocol/interface? I don't think MCP would work here?

small_scombrus: My local build of helix is 20MB, did you use the suggested flags on the install guide page?

lukaslalinsky: 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.

exidex: Have you tried Ki Editor[0]? It seems to be more into direction that you are looking for. It is not as mature as the rest of the editors but the editing model is definitely an improvement from ux perspective[0]: https://ki-editor.org/

clouedoc: With time I actually came to get accustomed to it and to enjoy my files not reloading automatically with Claude Code changes.

small_scombrus: > Is there some established AI-agnostic protocol/interface?AFAIK no

beefsack: The different bindings vs Vim was actually what stopped me using it. I really really wanted to love it and love a lot of the motivation and principles behind it, but unlearning decades of muscle memory is an absolute nightmare.

kubafu: 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.