>It's a joke. If Neovim is the modern Vim, then Helix is post-modern.
It's interesting that postmodern is so often used by people, perhaps less familiar with the arts and the humanities, to mean "an update to modern" or a progression thereof. They use it in a strictly literal sense, eschewing the precise meaning of the term they're referencing by mere addition of discontinuity as incremental difference.
Obviously, there's little impact to this. The term is hardly degraded by engineers advertising to other engineers. It looks a touch unread, but then again we have people like Thiel and Luckey misinterpreting Tolkien, so again it's hardly the most egregious example. I guess it just jumped out to me because I was hoping to see something creative truly postmodern.
That jumped out at me too the first time I ran into Helix making this joke, and I was also disappointed to find that they meant modern++.
That said, I’m not sure I agree with your assessment that it’s wrong, exactly. Postmodernism did indeed follow modernism and come into being as a reaction to modernism. So I think “postmodernism” has a naive and original sense of being “what follows modernism”. Decades (so many at this point!) of discourse have added layers to that and undermined it and generally made it more complex. But the underlying meaning of the term remains.
(If your instinct is to respond with arguments about how works not limited to late 20th century western culture can be nonetheless classified as postmodern, I hear you, but the fact that the term itself was only coined post modernism remains, and is all I’m pointing to.)
Personally, I get more hung up on people using “modern” to mean “new”. Then to use “postmodern” to mean “more new” while to my ears (eyes) it means “dated af” is even funnier and more jarring.
Helix, the first editor to not believe in grand narratives. Helix, the relativist editor. Helix, now updated with the latest from Foucault and Derrida!
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.
Curious to hear your gripes about modal editors! I'm a long time Emacs user (traditional keybindings, not evil-mode), but I also started using Vim in parallel a little over a decade ago. I feel very proficient/productive in both, regularly using many of Vim's more advanced motions and functionality. I generally love the power and composability of Vim text objects, and definitely experience the benefit of using them. But there are some times where I am doing things like many small edits within a line where rapidly changing modes for all of the edits starts to feel cumbersome.
For Emacs, I use multiple cursors and a treesitter-based plug-in for incrementally expanding or reducing the selection by text objects. I also have a collection of my own helper functions for working with text that make my non-modal Emacs approach still feel very comparable to the power of manipulating text in Vim.
Curious to hear if your issues with modal editing are similar.
My main gripe with modal editors is that they still use the Escape key to go back to normal mode even though Escape was chosen for historical reasons (used to sit much much closer to the home row on older Unix Keyboards)
In Linux and MacOs I can change it with just one gui setting but it's still annoying how everyone went with it. It's not mentionned in most vim tutorials. According to a vim reddit poll, at least half of the users are just using Escape where it is now instead of one of the alternatives. This is beyond me, it feels like someone inventing glasses in order to see better but everyone settled on cast iron frames.
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.
GitHub Copilot, Claude Code and Codex provide fairly good IDE integrations. They don't just edit files behind your back. They actually edit the files you have in the IDEs using editor APIs and even show you a nice diff view. This way you never have content that is out of sync. I find this approach very usable and appealing.
On the other hand, many of the AI tools and their companies think that you should completely ditch IDEs for CLIs only, because "nobody needs to write code anymore". Some of them even stopped maintaining IDE extensions and go all-in in CLIs.
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.
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?
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.
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
>eventually I just came to the conclusion the bindings are done the way they are due to simpler implementation, not simpler user interface
This was my general feel from using it for a bit too. I don't think that necessarily makes it a worse result (there's a form of user-facing consistency in 'this implements like that', it's just a bit meta), but it's one of the things that constantly pushed me away a bit. Some semi-common actions just didn't feel ergonomic, even after a couple weeks. (not implying that vim is a bastion of perfection, of course)
That said, I HIGHLY recommend people give Helix and/or Kakoune it a try. The different mental model is immediately compelling in some ways, and on balance I think it's a better approach. It's just that you have to weigh the details that might not work for you against all the other IDEs out there that have a heck of a lot more stuff already built for them... and it may mean you don't keep using them. Or you'll be thrilled with the end result.
I'm a very long time user of vi/vim, and I've gotten tired of maintaining vim configs. I've gotta have my LSPs and treesitters. I decided I wanted to move away from self maintenance and use something opinionated.
But, I found helix a little too opinionated. In particular, when you exit and go back into the file it won't take you back to where you were. I decided I'd start using helix on my "work journal" file which is over 20K lines and I edit somewhere towards but not at the end (done is above the cursor, to do and notes are below). Also, I NEED hard line wrapping for that.
Helix doesn't seem interested in incorporating either of those, which were "must haves" for me.
So I set the LLMs on it and they were able to make those changes, which was pretty cool. But I ended up deciding that I really didn't want to maintain my own helix fork for this, not really a plus over maintaining my vim config.
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.
what do you mean it does not have a simpler user interface? I found the combo of hx for quick edits/terminal work and Zed with hx bindings for everything else great.
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 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?
"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.
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.
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`.
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.
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.
I really want to like Helix, but I wish the developers paid more attention to performance, or were more receptive to outside contributions. Helix can really chug, even on small files, and the perception in the community seems to be "it's written in Rust so therefore it's blazingly fast :rocket-ship-emoji:"
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.
Those huge plugin files result from Rust duplicating libstd into each plugin at link time when crates are built as cdylib or staticlib, and you can prove it with cargo-bloat or by inspecting DT_NEEDED and symbol sizes with readelf -d and ldd.
If you control the build, force shared std linking with RUSTFLAGS='-C prefer-dynamic' and crate-type = ['dylib'] so host and plugins share libstd and accept the need for matching toolchains, or switch to a different plugin model like compiling to WASM and running modules with wasmtime or exposing a small C-ABI shim into a single shared runtime, and use strip plus LTO for quick size wins.
I switched from neovim because plugins and updates kept breaking it, and I never really did feel like I was in control of it anyway. Helix does what it does, no fuzz. Never breaks.
You do start to think “can I get helix keybindings in my shell”, though.
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
I was very enthusiastic about helix since it rethinks some of vim complexity. But lack of plugins makes it just an editor for small files only that I can quickly start on server and doesn’t not make it suitable for serious work.
You can select the current syntax object under the cursor with alt+o and expand the selection to the enclosing syntax objects with further presses of alt+o. This moves you automatically to the end of the selected syntax object. You can use alt+b to move to the beginning of the selected syntax object.
> "insert after this expression"
Select the expression and after that you can use regular commands like a and p.
[+] [-] lofatdairy|24 days ago|reply
>>Post-modern?!
>It's a joke. If Neovim is the modern Vim, then Helix is post-modern.
It's interesting that postmodern is so often used by people, perhaps less familiar with the arts and the humanities, to mean "an update to modern" or a progression thereof. They use it in a strictly literal sense, eschewing the precise meaning of the term they're referencing by mere addition of discontinuity as incremental difference.
Obviously, there's little impact to this. The term is hardly degraded by engineers advertising to other engineers. It looks a touch unread, but then again we have people like Thiel and Luckey misinterpreting Tolkien, so again it's hardly the most egregious example. I guess it just jumped out to me because I was hoping to see something creative truly postmodern.
[+] [-] ctmnt|24 days ago|reply
That said, I’m not sure I agree with your assessment that it’s wrong, exactly. Postmodernism did indeed follow modernism and come into being as a reaction to modernism. So I think “postmodernism” has a naive and original sense of being “what follows modernism”. Decades (so many at this point!) of discourse have added layers to that and undermined it and generally made it more complex. But the underlying meaning of the term remains.
(If your instinct is to respond with arguments about how works not limited to late 20th century western culture can be nonetheless classified as postmodern, I hear you, but the fact that the term itself was only coined post modernism remains, and is all I’m pointing to.)
Personally, I get more hung up on people using “modern” to mean “new”. Then to use “postmodern” to mean “more new” while to my ears (eyes) it means “dated af” is even funnier and more jarring.
Helix, the first editor to not believe in grand narratives. Helix, the relativist editor. Helix, now updated with the latest from Foucault and Derrida!
[+] [-] unknown|24 days ago|reply
[deleted]
[+] [-] the_hoser|24 days ago|reply
[+] [-] humanizersequel|24 days ago|reply
Could you provide an example / be more specific about this?
[+] [-] Curiositry|25 days ago|reply
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.
[+] [-] wilkystyle|25 days ago|reply
For Emacs, I use multiple cursors and a treesitter-based plug-in for incrementally expanding or reducing the selection by text objects. I also have a collection of my own helper functions for working with text that make my non-modal Emacs approach still feel very comparable to the power of manipulating text in Vim.
Curious to hear if your issues with modal editing are similar.
[+] [-] cassepipe|25 days ago|reply
[+] [-] the_killer|24 days ago|reply
[deleted]
[+] [-] bayesianbot|25 days ago|reply
[+] [-] small_scombrus|25 days ago|reply
I have reload-all bound to Ctrl-r
[+] [-] g947o|24 days ago|reply
On the other hand, many of the AI tools and their companies think that you should completely ditch IDEs for CLIs only, because "nobody needs to write code anymore". Some of them even stopped maintaining IDE extensions and go all-in in CLIs.
(I call that complete BS)
[+] [-] dayjah|25 days ago|reply
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.
[+] [-] clouedoc|25 days ago|reply
[+] [-] vaylian|25 days ago|reply
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?
[+] [-] burke|24 days ago|reply
https://github.com/burke/helix/pull/1
[+] [-] mgrandl|24 days ago|reply
[+] [-] lukaslalinsky|25 days ago|reply
[+] [-] exidex|25 days ago|reply
[0]: https://ki-editor.org/
[+] [-] itsn0tm3|25 days ago|reply
[0] https://github.com/usagi-flow/evil-helix
[+] [-] Groxx|24 days ago|reply
This was my general feel from using it for a bit too. I don't think that necessarily makes it a worse result (there's a form of user-facing consistency in 'this implements like that', it's just a bit meta), but it's one of the things that constantly pushed me away a bit. Some semi-common actions just didn't feel ergonomic, even after a couple weeks. (not implying that vim is a bastion of perfection, of course)
That said, I HIGHLY recommend people give Helix and/or Kakoune it a try. The different mental model is immediately compelling in some ways, and on balance I think it's a better approach. It's just that you have to weigh the details that might not work for you against all the other IDEs out there that have a heck of a lot more stuff already built for them... and it may mean you don't keep using them. Or you'll be thrilled with the end result.
[+] [-] linsomniac|24 days ago|reply
But, I found helix a little too opinionated. In particular, when you exit and go back into the file it won't take you back to where you were. I decided I'd start using helix on my "work journal" file which is over 20K lines and I edit somewhere towards but not at the end (done is above the cursor, to do and notes are below). Also, I NEED hard line wrapping for that.
Helix doesn't seem interested in incorporating either of those, which were "must haves" for me.
So I set the LLMs on it and they were able to make those changes, which was pretty cool. But I ended up deciding that I really didn't want to maintain my own helix fork for this, not really a plus over maintaining my vim config.
[+] [-] beefsack|25 days ago|reply
[+] [-] imjonse|25 days ago|reply
[+] [-] haxfn|25 days ago|reply
"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.
[+] [-] canistel|25 days ago|reply
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...
[+] [-] dilawar|25 days ago|reply
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?
[+] [-] kleiba|25 days ago|reply
You can configure every combination of keystrokes in Emacs - just bind M-ESC ESC to something harmless (such as, e.g., not function at all).
One possibility would be the following line in your ~/.emacs file:
[+] [-] weinzierl|25 days ago|reply
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.
[+] [-] lorenzohess|25 days ago|reply
[+] [-] korantu|25 days ago|reply
[1] https://zed.dev/
[+] [-] theusus|25 days ago|reply
[+] [-] kristiandupont|25 days ago|reply
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.
[+] [-] kubafu|25 days ago|reply
[+] [-] seg6|25 days ago|reply
For the curious: https://github.com/seg6/dotfiles/blob/1281626127dfbf584c2939...
[+] [-] qudat|24 days ago|reply
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.
[+] [-] rgoulter|25 days ago|reply
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.
[+] [-] assbuttbuttass|24 days ago|reply
[+] [-] Panzerschrek|25 days ago|reply
[+] [-] whytevuhuni|25 days ago|reply
I think 29MB is still huge for a terminal text editor, but nevertheless not "hundreds".
[+] [-] hrmtst93837|24 days ago|reply
If you control the build, force shared std linking with RUSTFLAGS='-C prefer-dynamic' and crate-type = ['dylib'] so host and plugins share libstd and accept the need for matching toolchains, or switch to a different plugin model like compiling to WASM and running modules with wasmtime or exposing a small C-ABI shim into a single shared runtime, and use strip plus LTO for quick size wins.
[+] [-] dalanmiller|25 days ago|reply
[+] [-] ctenb|25 days ago|reply
[+] [-] debois|24 days ago|reply
You do start to think “can I get helix keybindings in my shell”, though.
[+] [-] small_scombrus|25 days ago|reply
[+] [-] para_parolu|24 days ago|reply
[+] [-] bulbar|25 days ago|reply
"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.
[+] [-] vaylian|25 days ago|reply
> "Move to end of the scope"
You can select the current syntax object under the cursor with alt+o and expand the selection to the enclosing syntax objects with further presses of alt+o. This moves you automatically to the end of the selected syntax object. You can use alt+b to move to the beginning of the selected syntax object.
> "insert after this expression"
Select the expression and after that you can use regular commands like a and p.
[+] [-] srik|25 days ago|reply
https://neovim.io/doc/user/usr_04/#_text-objects
[+] [-] org3|24 days ago|reply