>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!
They are Tolkien fans and yet they are building the devices (Palantir, Anduril) which evil will eventually use to dominate. Palantir is well-named but tragic that a fan would build it. Anduril is poorly-named as it is the sword used to combat industrial power rather than represent it.
Except that, from that talk, Larry clearly has some idea about what the term postmodernism means in art & culture and isn’t just using it to mean “modern++”.
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.
I map caps to ctrl and do ctrl-[ to get to normal mode. The main reason is using Vim bindings in other editors where Esc can get intercepted by other bindings but ctrl-[ has always worked everywhere.
My opinion is that going back to normal mode is too important a key to be a key combo, and a weird one at that (is it [ or ] ?). I am pretty sure you can get used to it but we humans get used at anything. My pressing on CapsLock happens at a subconscious level. Quick edit and then punctuate with CapsLock with the pinkie. Some random key combo is not acceptable.
Cassepipe, it’s not a great default for sure. What do you have yours mapped to? I mapped jj to return to normal mode and also save my file. So, as I’m typing, I just hit jj, the jj vanishes, and this command is run:
<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 find the jj/jk hack a bit too clever for my taste. I just map CapsLock to Escape system-wide because it also unlocks quick escaping for shells vi-modes too and I realized that actually Escape is a really nice key to have around in a lot of UIs to get out/go back/cancel what you are doing. I also like that it's a simple gui setting away (or registry key editing in windows).
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)
What key would be a good candidate as a default though? Imagine the memes for exiting vim if you needed a modifier to get into normal mode. Caps lock is truly a useless key and should be escape anyway.
As someone who cut their teeth on a sun "programmer" layout, I really need control to be in that position. I might try mapping the vestigial control key to escape though. Or maybe the hack that dtj1123 describes (tap is escape, hold is control), if I can pull that off on macos.
<ctrl-[> always works out of the box which is less of a stretch than esc.
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.
I have caps remapped to esc when tapped, and ctrl when held. Takes perhaps a weekend to get used to, but once the muscle memory is there it feels incredibly comfortable and natural.
On macOS I use Karabiner-Elements to do the exact same thing. Also, my config is only applied in terminals, everywhere else the original functionality is kept. So, I'd say it is quite flexible.
I mean... if people don't mind reaching, so what? I purposefully don't remap my leader key, although I don't have many leader mappings so it's not like I'm reaching for it constantly.
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've noticed that Codex usually uses the native editing tools and shows me a diff, but sometimes it just sidesteps that and does a cat > file << EOF, so I need to rely on Git diffs to tell what it did.
> This way you never have content that is out of sync.
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 don’t even open a text editor anymore 90% of the time. Seems clear to me that IDEs, in the traditional sense, don’t really have a place in the future of software creation. They might morph into something that does, but definitely not in their current form, imo.
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.
Yes, that's what I said, I'm contrasting properly engineered AI code to vibe coded slop AI code, not that human written code is inherently better engineered.
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?
This is a distinctly Zed solution - trying to move the agent experience into the editor, rather than just giving the agent an interface with which to control and read from the editor.
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.
It's not just Zed, Emacs has has a thriving ACP implementation in agent-shell[0], and allows for some very cool integrations[1]. There are a fair number of other clients[2] as well.
The second half of this is spot on. The now is making IDEs that can integrate with agents, not the other way around. Soon the Claude and Codex will do that for us on their hosts and the argument is it will save sending the context up.
Just watching filesystem for file changes and updating the in-memory view of the file on any change? This isn’t really relevant to MCP, though one option is to provide a different tool to the AI agent for file modifications, which would make modifications through the file editor itself.
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.
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.
>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.
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
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
To some extend that is true for any opinionated piece of software. But that is a beauty of opensource don't use it if it doesn't match your idea of how that software should look like
It's not generated by LLM, it was actually my idea, but grammar-corrected by LLM, but you are not wrong either, the docs are really subpar in a lot of ways, and not clearly explaining why is one of them, and of course, the potentially cringey sentences too, someone complained the docs read like a Vogue magazine before lol
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.
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.
Yeah I always see this "issue" with Neovim and its almost entirely user-cultural, installing big blobs of plugins, updating to edge every day and some kind of jones's pressure.
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.
I just use neovim ;)
Just commented to inform.
But I can see the benefit of something like evil-helix, very limited setup being needed and getting features like LSP out of the box …
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.
> 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?
Yes, a slight misunderstanding, I only meant that the fact that K types in insert mode doesn't mean you move to Ctrl+N to replicate its functionality, you should still maintain the same position (K)
Sure, but [n]ext and [p]revious are common in the TUI world and which one makes more sense is debatable. There's decades of history behind the choice and while I prefer j/k I wouldn't call n/p wrong.
Yes, it's an very common mistake, there is also decades of history behind fixing it. But the debate here is not j/k vs [n]ew file/[p]rint file, but about the inconsistency of using one logic in navigating lines of text in an editor vs another in navigating lines of text in a file list
I'm pretty sure next and previous are older than new file and print file both of which have little use in this context. You could also see it as navigating lines of text vs navigating results in a list (ie search in less/vim) if you want to be pedantic. In (Neo)Vim <C-j> in insert mode inserts a new line below the current and <C-k> inserts digraphs. N/P are not necessarily inconsistent.
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.)
> How does the machine I ssh to know my keyboard layout
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)
The machines and coworkers I have have no idea what I am using
locally if they don't watch my typing, it could be QWERTZ or
Turkish-F it could be a chorded keyboard.
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.
It's good at least in my case because I switch between Dvorak (Corne) and Qwerty (laptop's keyboard) all the time, without positional keymap, I would have to develop two sets of muscle memory
The effective freedom to choose keyboards like Dvorak relates directly
to the privacy of a remote vi not breaking the privacy layer of this
abstraction. Do what we do because the servers won't be updated or
we will specifically lock their choices, etc..
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.
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?
I have in fact. I use Emacs for org-mode and markdown. Because of some reason, evil and org-mode did not mix well - for me. There is evil-org, which I did not try.
"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.
agreed, it wasn't more than a few days/a week. The real annoyance is if you use other coding environments too which do not have hx bindings (VScode, Google Colab) and have to constantly switch between hx and vim keys. Zed has had very good hx keybindings support for a few months now so this became less of an issue.
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.
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.
At least once a week I daydream about altering nushell so it can run helix as a subprocess for handling the editing parts. Maybe one day I'll go for it. Until then I'll just to make frequent use of the open-in-editor command.
I've always used GUIs and had to basically break my brain to learn vim keybindings (in Sublime Text) some time ago and the helix bindings are just different enough to throw me off. Sucks because I would prefer an out-of-box solution that "just works" and I'm comfortable in across all my machines for terminal text editing.
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 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.
> 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.
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 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.
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.
That’s a perfectly fine usecase. But all systems I work with have vim installed by default anyway.
And vim handles big files better than helix (not sure why)
Just to be clear: it’s not suitable for me to do work using this editor.
There are many features lacking that makes me more efficient. In case of vim that is solved by a few plugins. It’s not about being IDE but rather about being well fitted tool. I wish I would only need LSP but it’s not enough for my work.
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'm in a similar boat. It's become my primary editor but I still open VSCode everytime I need search-and-replace or an easy git-blame.
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
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.
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 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 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.
Language grammars are ~200-250MB though.
They are in a separate folder, and often they are all bundled to support all the languages.
Some of them are HUGE.
.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.so
That's exactly what I found. Why these files should exist at all? Some other IDEs just have a bunch of highlighting rules based on regular expressions and have a folder of tiny XML grammar files instead of a folder of bloaty shared libraries.
Because it's far more reliable to use proper parsers instead of a bunch of regular expressions. Most languages cannot be properly parsed with regexes.
Those files are compiled tree-sitter grammars, read up on why it exists and where it is used instead of me poorly regurgitating official documentation:
That would waste CPU time and introduce additional delays when opening files.
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:
If disk space is important for your use case, I guess filesystem compression would save far more than just compressing binaries with upx. btrfs+zstd handle those .so well:
$ 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 184M
For real parsing a proper compiler codebase (via a language server implementation) should be used. Writing something manually can't work properly, especially with languages like C++ and Rust with complex includes/imports and macros. Newer LSP editions support syntax-based highlighting/colorizing, but if some LSP implementation doesn't support it, using regexp-based fallback is mostly fine.
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 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.
This is only tangentially related, but regarding:
>>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 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!
>we have people like Thiel and Luckey misinterpreting Tolkien
Could you provide an example / be more specific about this?
They are Tolkien fans and yet they are building the devices (Palantir, Anduril) which evil will eventually use to dominate. Palantir is well-named but tragic that a fan would build it. Anduril is poorly-named as it is the sword used to combat industrial power rather than represent it.
Peter Thiel owns a company called Palantir that designs its offices to look like Hobbiton.
It might be less of a misinterpretation and more of an on the nose joke about being overtly evil.
Blame Perl. As far as I can tell, they started it.
Source: https://www.wall.org/~larry/pm.html
Except that, from that talk, Larry clearly has some idea about what the term postmodernism means in art & culture and isn’t just using it to mean “modern++”.
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.
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.
I map caps to ctrl and do ctrl-[ to get to normal mode. The main reason is using Vim bindings in other editors where Esc can get intercepted by other bindings but ctrl-[ has always worked everywhere.
My opinion is that going back to normal mode is too important a key to be a key combo, and a weird one at that (is it [ or ] ?). I am pretty sure you can get used to it but we humans get used at anything. My pressing on CapsLock happens at a subconscious level. Quick edit and then punctuate with CapsLock with the pinkie. Some random key combo is not acceptable.
Cassepipe, it’s not a great default for sure. What do you have yours mapped to? I mapped jj to return to normal mode and also save my file. So, as I’m typing, I just hit jj, the jj vanishes, and this command is run:
<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 find the jj/jk hack a bit too clever for my taste. I just map CapsLock to Escape system-wide because it also unlocks quick escaping for shells vi-modes too and I realized that actually Escape is a really nice key to have around in a lot of UIs to get out/go back/cancel what you are doing. I also like that it's a simple gui setting away (or registry key editing in windows).
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)
Yea for me capslock is a systemwide esc for me. Works great.
What key would be a good candidate as a default though? Imagine the memes for exiting vim if you needed a modifier to get into normal mode. Caps lock is truly a useless key and should be escape anyway.
As someone who cut their teeth on a sun "programmer" layout, I really need control to be in that position. I might try mapping the vestigial control key to escape though. Or maybe the hack that dtj1123 describes (tap is escape, hold is control), if I can pull that off on macos.
<ctrl-[> always works out of the box which is less of a stretch than esc.
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.
I have caps remapped to esc when tapped, and ctrl when held. Takes perhaps a weekend to get used to, but once the muscle memory is there it feels incredibly comfortable and natural.
Which tool can do that kind of wizardry? I've seen either but not both.
On macOS I use Karabiner-Elements to do the exact same thing. Also, my config is only applied in terminals, everywhere else the original functionality is kept. So, I'd say it is quite flexible.
Is this macro mapped in vim or OS level? Sounds interesting.
Last time I checked, on all OSes you need to install some third-party software alas. Hopefully I am wrong now.
I configure it in the firmware of my keyboard with QMK
I have hesitated many times to set this up but I don't want to get used to something that I cannot set up in less than 30 seconds on a new machine.
Not having Escape where CapsLock sits on a new machine already makes it infuriatingly unusable already :)
I mean... if people don't mind reaching, so what? I purposefully don't remap my leader key, although I don't have many leader mappings so it's not like I'm reaching for it constantly.
I refuse to take a second look at this project until it has a functioning plugin system
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
Same!
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 call that complete BS)
I've noticed that Codex usually uses the native editing tools and shows me a diff, but sometimes it just sidesteps that and does a cat > file << EOF, so I need to rely on Git diffs to tell what it did.
> This way you never have content that is out of sync.
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 don’t even open a text editor anymore 90% of the time. Seems clear to me that IDEs, in the traditional sense, don’t really have a place in the future of software creation. They might morph into something that does, but definitely not in their current form, imo.
If you actually want to engineer properly and review the code rather than pushing out vibe coded slop PRs, then IDEs absolutely do have a future.
> If you actually want to engineer properly.
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.
Yes, that's what I said, I'm contrasting properly engineered AI code to vibe coded slop AI code, not that human written code is inherently better engineered.
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.
The latter is pretty easy to vibe-patch in:
https://github.com/burke/helix/pull/1
With time I actually came to get accustomed to it and to enjoy my files not reloading automatically with Claude Code changes.
> 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?
ACP Agent Client Protocol https://agentclientprotocol.com/get-started/registry
This is a distinctly Zed solution - trying to move the agent experience into the editor, rather than just giving the agent an interface with which to control and read from the editor.
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.
It's not just Zed, Emacs has has a thriving ACP implementation in agent-shell[0], and allows for some very cool integrations[1]. There are a fair number of other clients[2] as well.
[0]: https://github.com/xenodium/agent-shell
[1]: https://www.youtube.com/watch?v=HJQ86HuSIJI
[2]: https://agentclientprotocol.com/get-started/clients
The second half of this is spot on. The now is making IDEs that can integrate with agents, not the other way around. Soon the Claude and Codex will do that for us on their hosts and the argument is it will save sending the context up.
Just watching filesystem for file changes and updating the in-memory view of the file on any change? This isn’t really relevant to MCP, though one option is to provide a different tool to the AI agent for file modifications, which would make modifications through the file editor itself.
> Just watching filesystem for file changes
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.
> Is there some established AI-agnostic protocol/interface?
AFAIK no
ACP?
https://agentcommunicationprotocol.dev/introduction/welcome
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.
>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.
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
To me, what you describe is a red flag.
For example, that doesn't sound like they will take feedback from the community serious.
To some extend that is true for any opinionated piece of software. But that is a beauty of opensource don't use it if it doesn't match your idea of how that software should look like
It's not generated by LLM, it was actually my idea, but grammar-corrected by LLM, but you are not wrong either, the docs are really subpar in a lot of ways, and not clearly explaining why is one of them, and of course, the potentially cringey sentences too, someone complained the docs read like a Vogue magazine before lol
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.
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.
Yeah I always see this "issue" with Neovim and its almost entirely user-cultural, installing big blobs of plugins, updating to edge every day and some kind of jones's pressure.
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.
They don't have LTS releases, there is always a bug somewhere and the bug fix includes a number of features, if not new dependencies.
I just use neovim ;) Just commented to inform. But I can see the benefit of something like evil-helix, very limited setup being needed and getting features like LSP out of the box …
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.
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.
Wait, helix has a file explorer now? The lack of one has been preventing me from using it more
It does, but iirc, it’s only an explorer and isn’t able to delete, rename, or create.
Been playing with agent strategies, vibe coding this: https://github.com/hbbio/rc that uses helix by default
Using it already (the granular branch) but it's far from stabilized...
> 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?
Nope, you'd then do Ctrl+K, not N
(Neo)Vim omnifunc? Ctrl+k does nothing in my setup, probably your config or a plugin. Or am I misunderstanding what you mean?
Yes, a slight misunderstanding, I only meant that the fact that K types in insert mode doesn't mean you move to Ctrl+N to replicate its functionality, you should still maintain the same position (K)
Sure, but [n]ext and [p]revious are common in the TUI world and which one makes more sense is debatable. There's decades of history behind the choice and while I prefer j/k I wouldn't call n/p wrong.
Yes, it's an very common mistake, there is also decades of history behind fixing it. But the debate here is not j/k vs [n]ew file/[p]rint file, but about the inconsistency of using one logic in navigating lines of text in an editor vs another in navigating lines of text in a file list
> consistent and transferable keybinds
I'm pretty sure next and previous are older than new file and print file both of which have little use in this context. You could also see it as navigating lines of text vs navigating results in a list (ie search in less/vim) if you want to be pedantic. In (Neo)Vim <C-j> in insert mode inserts a new line below the current and <C-k> inserts digraphs. N/P are not necessarily inconsistent.
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.)
> How does the machine I ssh to know my keyboard layout
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)
The machines and coworkers I have have no idea what I am using locally if they don't watch my typing, it could be QWERTZ or Turkish-F it could be a chorded keyboard.
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.
It's good at least in my case because I switch between Dvorak (Corne) and Qwerty (laptop's keyboard) all the time, without positional keymap, I would have to develop two sets of muscle memory
The effective freedom to choose keyboards like Dvorak relates directly to the privacy of a remote vi not breaking the privacy layer of this abstraction. Do what we do because the servers won't be updated or we will specifically lock their choices, etc..
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.
it's either ragebait or smth. Helix is not C++ and never would be it. Vim is C, Neovim is C++
People really need to stop making analogies and saying what things really are.
I agree. Helix is more like ruby on rails.
I will try ki editor
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 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 would press ESC repeatedly in Emacs, three of which are enough close a window.
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:
Thank you for mentioning this. I do have something similar...
Is this kind of comment not just a tautological rebuttal to any criticism of emacs
Have you tried Emacs' Extensible Vi Layer ("Evil" mode)? My muscle memory switched almost seamlessly from Vim to Emacs with Evil mode
I have in fact. I use Emacs for org-mode and markdown. Because of some reason, evil and org-mode did not mix well - for me. There is evil-org, which I did not try.
"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.
agreed, it wasn't more than a few days/a week. The real annoyance is if you use other coding environments too which do not have hx bindings (VScode, Google Colab) and have to constantly switch between hx and vim keys. Zed has had very good hx keybindings support for a few months now so this became less of an issue.
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/
Neovim supports LSP out of the box since version 0.11. It requires very little configuration to enable and configure it.
It actually has Helix bindings as well which makes the investment in Helix not that risky anymore. I use both.
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.
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.
At least once a week I daydream about altering nushell so it can run helix as a subprocess for handling the editing parts. Maybe one day I'll go for it. Until then I'll just to make frequent use of the open-in-editor command.
I've always used GUIs and had to basically break my brain to learn vim keybindings (in Sublime Text) some time ago and the helix bindings are just different enough to throw me off. Sucks because I would prefer an out-of-box solution that "just works" and I'm comfortable in across all my machines for terminal text editing.
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.
> 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.
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.
> 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?
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.
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.
Agreed. But very useful for quick editing, and easier to install than vim on Windows.
That’s a perfectly fine usecase. But all systems I work with have vim installed by default anyway. And vim handles big files better than helix (not sure why)
why? There is LSP support included. Pretty usable. Of course this is not fully IDE, but I don't expect this from "editor"
Just to be clear: it’s not suitable for me to do work using this editor. There are many features lacking that makes me more efficient. In case of vim that is solved by a few plugins. It’s not about being IDE but rather about being well fitted tool. I wish I would only need LSP but it’s not enough for my work.
I've used Helix as my main editor over the past few years, I love it, but the speed of development is quite slow.
Would love to see some AI related plug-ins when the plug-in system is finally released.
I can’t believe it still doesn’t have plugins. That’s crazy. They’ve been working on that for so many years.
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 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.
I'm in a similar boat. It's become my primary editor but I still open VSCode everytime I need search-and-replace or an easy git-blame.
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.
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
I love helix. Incredibly snappy and minimalistic but still having every feature a serious IDE needs, out of the box.
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 open that pull request from time to time to check the progress. Want them to release it so bad
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.
Helix has built-in Tree Sitter support.
> "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.
Neo/vim does this with community and built-in “text objects”.
https://neovim.io/doc/user/usr_04/#_text-objects
These are great. I really have come to love this little plugin that extends and creates a/i textobjects:
https://github.com/nvim-mini/mini.ai
https://ki-editor.org/docs/introduction
I was really hoping this would have a postmodernist aesthetic
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 have been using helix for over a year now. I love it.
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
Helix deez nuts
ohh Ki and Helix on the front page today... it's a good day! :)
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.
this doesn’t address all your concerns but i use “X” to select lines above:
[keys.select] X = "select_line_above"
A new version should arrive this month or the next one. I think it’s worth trying it again then
Cool. Any information on what will be included in the next release?
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.
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".
Language grammars are ~200-250MB though. They are in a separate folder, and often they are all bundled to support all the languages. Some of them are HUGE.
That's exactly what I found. Why these files should exist at all? Some other IDEs just have a bunch of highlighting rules based on regular expressions and have a folder of tiny XML grammar files instead of a folder of bloaty shared libraries.
Because it's far more reliable to use proper parsers instead of a bunch of regular expressions. Most languages cannot be properly parsed with regexes.
Those files are compiled tree-sitter grammars, read up on why it exists and where it is used instead of me poorly regurgitating official documentation:
https://tree-sitter.github.io/tree-sitter
Funny enough, they are less than 10MB when compressed. I guess they could use something like upx to compress these binaries.
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?
That would waste CPU time and introduce additional delays when opening files.
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:
If disk space is important for your use case, I guess filesystem compression would save far more than just compressing binaries with upx. btrfs+zstd handle those .so well:I mean, they could decompress it once when using a language for the first time. It will still be fully offline, but with a bit uncompressing.
If this is a concern, why not compress at the filesystem level?
For real parsing a proper compiler codebase (via a language server implementation) should be used. Writing something manually can't work properly, especially with languages like C++ and Rust with complex includes/imports and macros. Newer LSP editions support syntax-based highlighting/colorizing, but if some LSP implementation doesn't support it, using regexp-based fallback is mostly fine.
My local build of helix is 20MB, did you use the suggested flags on the install guide page?
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 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.