Hacker News new | past | comments | ask | show | jobs | submit

Helix: A post-modern text editor

https://helix-editor.com/
loading story #47290012
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.

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.
I know it's not a proper fix, but helix does have `:reload` and `:reload-all` commands

I have reload-all bound to Ctrl-r

I was feeling this pain also; so I switched my workflow to watching file changes with lazygit, and then switching to helix to make small tweaks.

Another option you may want to try is mux (github.com/coder/mux). It wraps the LLM in a nice interface which has the ability to do line/block comments on changes by the LLM that then goes goes into your next prompt. It’s very early stage though: v0.19.0.

> you can only use AI on Helix through LSP

How do other editors do this, if they don't use LSPs? Helix specifically choses LSP as the integration mechanism (in combination with 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?

loading story #47286500
loading story #47285633
loading story #47285233
With time I actually came to get accustomed to it and to enjoy my files not reloading automatically with Claude Code changes.
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.

But how is ki like rust, and why is that significant? Helix is pretty rad, even if what you say is true.
> 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`?

I've never used Helix, but this exists in vim too, but it the autocompletion, because in that context hitting k would type k. Makes sense right? I'm guessing hitting k in Helix file explorer has a similar use, maybe searching?

loading story #47286478
I'm puzzled by the idea that positional constant is good for key bindings. How does the machine I ssh to know my keyboard layout or whether I am using a input with a related positional concept? (I suppose I should say I was puzzled by it, and now I am puzzled why this idea is back yet again.)
loading story #47286244
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.
loading story #47286531
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/

Vis editor [0] also has multicursor and powerful sam's structural regular expression

[0]: https://github.com/martanne/vis

Hadn't heard of this. So I looked at the docs for Ki.

I see the "Why Ki?", and then it has this:

> Being first-class means that it is not an extra or even sidekick; it is the protagonist.

Eh.

I find it quite off putting.

I guess my expectation is that someone enthusiastic enough to write a text editor with a value proposition of "it's got good tree-sitter-based navigation" would want to discuss why they thing syntactic selection is neat.

Seeing cliche LLMisms doesn't signal the same level of care to me.

Having been in the community for some time, it is just how the authors are, very enthusiastic about the wording. They like to come up with some wild terms explaining different behaviors and reasoning behind those behaviors, like "positional coherence" or "behavioral asymmetry", and the term "kimmunity" to reference to ki editor community. On a surface level, sure, it looks LLM generated, but I would be very surprised if they used LLM to generate that sentence. I choose to look at the actual meaning of the content and what they are trying to do differently
loading story #47286292
loading story #47286301
There is also evil-helix [0] a helix fork with vim bindings. Maybe that‘s something you would enjoy :)

[0] https://github.com/usagi-flow/evil-helix

at that point… use vim? genuinely asking. what does this get you?
Not having to deal with neovim plugins is a HUGE win. Using neovim with plugins feels like using a rolling Linux distro, you never know what breaks next. That's what I use zed, personally. It's the best modern vi-like editor, in my opinion.
> Using neovim with plugins feels like using a rolling Linux distro, you never know what breaks next.

You can just… not update them.

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

loading story #47286488
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?

I think Zed editor has helix phylosophy of supporting LSP out of the box while having exact vi bindings if it is important.

[1] https://zed.dev/

loading story #47286487
Have you tried Emacs' Extensible Vi Layer ("Evil" mode)? My muscle memory switched almost seamlessly from Vim to Emacs with Evil mode
"However, I have vim muscle memory built over 25 years of use."

Me too and it took a view attempts but I'm on Helix now and don't regret it. Once you are over the most prominent discrepancies like dd and G it's an uphill battle.

loading story #47286513
loading story #47290829
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 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.

> For large edits, most selections will be out of the scroll window and not really helping.

That's why the Ki editor has a feature called Reveal Cursors (https://ki-editor.org/docs/normal-mode/space-menu#-cursor-re...), which is specifically made to solve this issue

> only really helps when you can see everything you're about to change on the screen

Which is still a net positive over the alternative?

loading story #47289322
loading story #47288204
loading story #47288730
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.

loading story #47288628
This.

I tried it out for a few days, and I cannot justify spending time on this when I am already very productive with vim/VSCodeVim. Helix is nice in many ways but not worth switching over

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.

loading story #47289157
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
Love `hx`, vim never really clicked for me and the batteries-included nature of helix is one of its best selling points.
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.

loading story #47286284
loading story #47286625
loading story #47289215
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.
loading story #47289580
loading story #47288614
loading story #47288331
A new version should arrive this month or the next one. I think it’s worth trying it again then
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.
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".

loading story #47285436
My local build of helix is 20MB, did you use the suggested flags on the install guide page?
loading story #47289600
{"deleted":true,"id":47285035,"parent":47282701,"time":1772864781,"type":"comment"}
loading story #47289366
loading story #47286317
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.