Helix: A post-modern text editor
helix-editor.com
helix-editor.com
>>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.
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!
I definitely agree that, strictly speaking, postmodernism is a somewhat loose label for an eclectic set of ideas and expressions following modernism. My issue was not with the label being denotatively incorrect – that postmodernism implies a deliberate and retrospective relation to what is labeled "modern" – but rather that the term invokes a spirit that is utterly missing from the project.
There is no rejection of teleological narratives, and in fact by misapplying this term acts to reinforcing them. It doesn't meaningful critique the projects its in conversation with except in terms that reinforce the underlying assumptions that motivated their production. It critiques Vim in terms of codebase complexity and multiplexity, and these concepts are nothing if not deeply familiar. Even with regards to the concept of coding as the composition and production of language, Helix only looks to make that process more efficient, rather than examine how this process reproduces itself, or how intent is masked and produced through abstraction and reference to the work of other programmers/authors.
I am not saying that it should have done that. It is by all means a perfectly good editor. But a perfectly good editor does not a postmodern editor make.
If anything, one could argue that the process of vibecoding is more recognizably postmodern, especially as a strict rejection of the modernist belief system that produces that process of coding. Its nondeterminism rejects efficient, coherent processes. It requires one to reimagine production as its ends, rather than by beginning with conventional initialization rituals. Its discursive rather than dictatorial.
Not to say vibecoding is the end of coding or even the way "forward", just as to say postmodernism is not the teleological end to thought.
Good point on vibing though.
Could you provide an example / be more specific about this?
It might be less of a misinterpretation and more of an on the nose joke about being overtly evil.
This is not to say that Tolkien's authorial intent is final, nor necessarily discernible, but we are obligated to examine the palantirs' presentation as not just a passive object with certain, defined qualities, but as devices that have their own consequential histories within the narrative. Thiel naming his company after a tool presented textually as fallible, misleading, and myopic (in addition to its obvious power) with ostensibly no desire to attach such connotations to the company requires, in my mind, at least a superficial reading. We can even disregard the fact that these were mostly tools for an evil opposed by Tolkien, and not make the (valid) argument that their presentation within the text is could be considered direct argument in opposition to their creation. I personally think that to build a company and name it after a work that argues against that company's mission/purpose requires misinterpretation of the reference material, both in terms of poor comprehension of metaphor and as a poor response to the text and the body of discourse that surrounds and infuses it.
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.
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.
- I have nomouse mode on, to try to learn modal editors properly. But the mouse is actually fairly fast for getting to a specific cursor position. In theory, using Helix motions could be faster (and there's gw if I don't know what motion to use). In practice, the mental process of turning a point on the coordinate plane into the correct series of motions (including i) feels vastly slower.
Still, Vim, Helix, etc are incredible for structural manipulation of text, and I miss what they provide any time I edit text somewhere else, even with the universal keybindings that are available for navigating/selecting/deleting words, lines, etc. I tried Vim mode in Zed and it just didn't cut it.
Some things about Helix that I particularly like: speed and stability (no weird lag on visual block insert!), the jump to diagnostics/changes pattern (]d <Space>a is a surprisingly nice spellcheck interface, with <Space>d for the overview), the jumplist, and the good-by-default fuzzy pickers.
<Esc>:w<CR>
I could just have it escape instead without saving.
If I hadn’t chose jj it would have been ff, which is also always under an index finger. I do wish I’d been clued into the idea when I started with Vim instead of two years later.
I either put CapsLock where Escape sits or use both shifts simultaneously (one cancels it) but even then I almost never use it. The rare times I need to type a lot of uppercase together is generally code in vim and visual selection + gU does the job.
The point of my comment was not to shill for a particular solution though but for the vim community to acknowledge the problem publicly instead of it being some insider knowledge you discover in a random internet comment six months into fighting vim (if you haven't dropped out yet)
I do jk as I always find a roll easier on the fingers than a double-tap jj or kk. You could also use space provided you aren't using one of those distros that bases its identity on the spacebar.
Not having Escape where CapsLock sits on a new machine already makes it infuriatingly unusable already :)
ZMK (or it's free software cousin QMK) are super flexible and you can create lots of custom behaviors for keys (tap/hold behaviors, double press, layering, etc...). It takes some time and effort to learn how to set it all up. Some of the more complicated behaviors require using their dsl for mapping the keys instead of their GUI editor. Considering the ridiculous amount of hours I spend at my computer using a keyboard, I felt it was worth the investment in learning.
No but really, vim's paradim that you should go back to normal mode constantly. With the current situation you get posts on the vim subreddit asking/telling you about insert mode editing commands. You might as well use Emacs at that point, at least it would be the intended workflow
But again my point is that the default sucks. You probably learned a about Ctrl + [ while looking online for alternatives after realizing the default sucked
I have reload-all bound to Ctrl-r
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?
AFAIK no
Not only do the most popular editors have little-to-no incentive to implement it (they’re more interested in pushing their own first-class implementations, rather than integrating those of others), it’s much more work to integrate the evolving agent experience into the IDE than it would be to provide IDE integration points for the agents themselves.
So, I think this project would have been much more successful if it had been more focussed on keeping the agent and IDE experiences separated but united by the protocol, instead of trying to deeply marry them. But that’s not in line with Zed’s vision and monetization strategy.
It won’t be long before the big players start to release their own cloud-based editors. They’ll be cloud-based because the moat is wider, and they’ll try to move coding to the cloud in the way that Google Workspaces moved docs to the cloud. Probably with huge token discounts to capture people. If you squint, you can already see this starting to happen with Claude Desktop, which runs its agent loop on the cloud (you can tell because skills appear to need to be uploaded).
Notably, Microsoft, with VSCode and GitHub have a web-based editor advantage in this space, but no models.
[0]: https://github.com/xenodium/agent-shell
This is non-trivial, if you want to do it efficiently. On Linux you can set up an inotify listener for individual files, but not for entire directories. This also breaks down if you are working with data on non-local drives.
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.
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)
I think this statement is misguided, and potentially comes from a lack of experience in getting AI coders to produce quality.
Proper engineering does not come about from the tools you use or how you use them. Proper engineering has always come from thought, and reasoning, it never was about the act of coding. It always was about the systems thinking and expressing the goals and desires that matched the requirements.
IDEs were never needed to properly engineer and in the days of AI will become increasingly less important.
Tools for planning, reviewing, and commenting on code are the future. The necessity to edit actual code is coming to an end.
They can definitely go out of sync, particularly if something that isn't the editor or the AI changes the code (e.g. running shell commands or opening the file in a different editor and making changes there). I've had a whole load of issues with VSCode where there's been spurious edits all over the place that show up again even if I try and revert them, because every time the AI makes an unrelated edit, VSCode tries to reset the file to the version it thinks exists and then play the AI's edits on top.
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.
For example, that doesn't sound like they will take feedback from the community serious.
You can just… not update them.
These days you can probably install mini.vim to get basically every paper cut fixed (eg extra "surround objects", aligning text, plugin manager etc), a theme, a few other assortments to taste and park your plugins at known commits or include them in your dotfiles and its ... fine. I haven't updated my plugins in probably 6 months and when I do I update them selectively only if there is actually a reason to do it or the changes are very minor.
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.
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.
"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.
Why does it need to? If you are using say, Dvorak, you can just pick the keyboard layout by pressing `*` (a keybinding which is not affected by the chosen keyboard layout)
Going backwards to layout makes no sense to me. They then can't tell me what to type, we get to fight about env defaults, etc.. And for what? If your composition is any good it is approaching the abstract of code so looking at your hands and some visual feedback is of little value as it traverses the whole context.
After a few years of trying to get along directly in local pair programming or similar with people with local largely insane keymaps I decided to make use of fences and privacy making good neighbors and I don't want those fences ruined.
Even without my intended uses for this abstraction, positional habits is the first step of getting people out of the crib, a crib is easy to sell a start in but not a place to retire.
Helix OTOH looks good.
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?
> consistent and transferable keybinds
> if you want to be pedantic
I don't, the question is how you justify that in the search for consistency? I don't get the C-j, the issue with consistency is J/K, why do digraphs matter, are they more important than basic navigation?
I'm not sure the first programs could handle more than one, and (neo)vi(m) just uses :e, for edit. New or existing is irrelevant, it's not Microsoft Word.
> is [p]age up old enough
Is this a real thing? I only know of [f]orward/[b]ack and [d]own/[u]p.
> are they more important than basic navigation
Don't put words in my mouth, but sure in insert mode you're not supposed to navigate, but this discussion is getting off-topic.
Using it already (the granular branch) but it's far from stabilized...
I will try ki editor
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...
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?
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.
[1] https://zed.dev/
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:
(global-set-key (kbd "M-ESC ESC") 'keyboard-quit) (global-unset-key (kbd "ESC ESC ESC"))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.
Which is still a net positive over the alternative?
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
In Emacs, there's an mc-hide-unmatched-lines command that temporarily hides the lines between the ones with cursors. This makes multiple cursors usable with up to a screen-height number of items (being able to place cursors by searching for a regexp helps).
I agree, though - MCs are most useful for simple, localized edits. They're nice because they don't require you to mentally switch between interactive and batch editing modes, while still giving you some of the batch mode benefits. For larger or more complex edits, a batch-mode tool ("Search and replace", editable occur-mode in Emacs, or even shelling out to sed) is often a better choice.
I don't really care about that. Just for fun, and because I can, sometimes I edit huge SQL files using multiple cursors, meaning they are much bigger than just some KBs. Hundreds of cursors, all working at the same time, it is wonderful.
For the curious: https://github.com/seg6/dotfiles/blob/1281626127dfbf584c2939...
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.
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 think 29MB is still huge for a terminal text editor, but nevertheless not "hundreds".
.rwxr-xr-x 4.6M aa 6 Mar 21:52 ocaml-interface.so
.rwxr-xr-x 4.6M aa 6 Mar 21:52 rpmspec.so
.rwxr-xr-x 4.9M aa 6 Mar 21:52 tlaplus.so
.rwxr-xr-x 5.1M aa 6 Mar 21:52 ocaml.so
.rwxr-xr-x 5.1M aa 6 Mar 21:52 c-sharp.so
.rwxr-xr-x 5.3M aa 6 Mar 21:52 kotlin.so
.rwxr-xr-x 5.4M aa 6 Mar 21:52 ponylang.so
.rwxr-xr-x 5.5M aa 6 Mar 21:52 slang.so
.rwxr-xr-x 6.1M aa 6 Mar 21:52 crystal.so
.rwxr-xr-x 6.8M aa 6 Mar 21:52 fortran.so
.rwxr-xr-x 9.2M aa 6 Mar 21:52 nim.so
.rwxr-xr-x 9.5M aa 6 Mar 21:52 julia.so
.rwxr-xr-x 9.9M aa 6 Mar 21:52 sql.so
.rwxr-xr-x 16M aa 6 Mar 21:52 lean.so
.rwxr-xr-x 18M aa 6 Mar 21:52 verilog.so
.rwxr-xr-x 22M aa 6 Mar 21:52 systemverilog.soThose files are compiled tree-sitter grammars, read up on why it exists and where it is used instead of me poorly regurgitating official documentation:
The whole Linux release is 15mb, but it uncompresses to 16MB binary and 200MB grammars on disk.
Why do we need to have 40MB of Verilog grammars on disk when 99% of people don't use them?
They could probably lazily install the grammars like neovim does, but as someone who doesn't have much faith in the reliability of internet infrastructure, I'll personally take it...
Just ran `:TSInstall all` in neovim out of curiosity, and the results were predictable:
~/.local/share/nvim/lazy/nvim-treesitter/parser
files 309
size 232M
/usr/lib/helix/runtime/grammars
files 246
size 185M
$ compsize ~/.local/share/nvim/lazy/nvim-treesitter/parser
Type Perc Disk Usage Uncompressed Referenced
TOTAL 11% 26M 231M 231M
$ compsize /usr/lib/helix/runtime/grammars
Type Perc Disk Usage Uncompressed Referenced
TOTAL 12% 23M 184M 184MYou do start to think “can I get helix keybindings in my shell”, though.
"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.
My experience had been that such plugins tend to need a lot of tuning to work flawlessly, which I don't like to do anymore.
I like to live default mode for the most part, but for that a piece of technology must be dedicated to a smooth out of the box experience. But all that fancy neovim/dwm/... ecosystem tend to be "we provide you a great framework to create your own things", which is nice, but not for me.
> "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.
Would love to see some AI related plug-ins when the plug-in system is finally released.
My vim muscle memory is too strong and stubborn.
For unselect, if I'm understanding correctly, ; will unselect with your cursor at the end of the selection, Alt-; will unselect and move your cursor back to the beginning.
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
> Post-modern?!
It's a joke. If Neovim is the modern Vim, then Helix is post-modern.
> Is it any good?
Yes.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.
[keys.select] X = "select_line_above"
Come on, jump out of your comfort bubble.