"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.
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
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.
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 reload-all bound to Ctrl-r
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?
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.
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.
AFAIK no
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...
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)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?
[1] https://zed.dev/
Me too and it took a view attempts but I'm on Helix now and don't regret it. Once you are over the most prominent discrepancies like dd and G it's an uphill battle.
I 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.
For the curious: https://github.com/seg6/dotfiles/blob/1281626127dfbf584c2939...
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.
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.
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
Which is still a net positive over the alternative?
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.
"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.
> Post-modern?!
It's a joke. If Neovim is the modern Vim, then Helix is post-modern.
> Is it any good?
Yes.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 184M