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.
wilkystyle 6 hours ago [-]
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.
cassepipe 3 hours ago [-]
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.
dtj1123 30 minutes ago [-]
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.
andrewl 3 hours ago [-]
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.
cassepipe 3 hours ago [-]
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)
zargon 1 hours ago [-]
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.
bayesianbot 11 hours ago [-]
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 call that complete BS)
yonatan8070 29 minutes ago [-]
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.
buzzerbetrayed 2 hours ago [-]
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.
satvikpendem 1 hours ago [-]
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.
small_scombrus 11 hours ago [-]
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
dcre 5 hours ago [-]
Same!
clouedoc 11 hours ago [-]
With time I actually came to get accustomed to it and to enjoy my files not reloading automatically with Claude Code changes.
dayjah 9 hours ago [-]
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.
vaylian 11 hours ago [-]
> 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?
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.
yammosk 22 minutes ago [-]
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.
spudlyo 4 hours ago [-]
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.
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.
vaylian 7 hours ago [-]
> 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.
small_scombrus 11 hours ago [-]
> Is there some established AI-agnostic protocol/interface?
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.
efnx 8 hours ago [-]
But how is ki like rust, and why is that significant? Helix is pretty rad, even if what you say is true.
n_kr 6 hours ago [-]
Wait, helix has a file explorer now? The lack of one has been preventing me from using it more
christophilus 5 hours ago [-]
It does, but iirc, it’s only an explorer and isn’t able to delete, rename, or create.
hbbio 3 hours ago [-]
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...
worksonmine 8 hours ago [-]
> 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?
eviks 7 hours ago [-]
Nope, you'd then do Ctrl+K, not N
worksonmine 5 hours ago [-]
(Neo)Vim omnifunc? Ctrl+k does nothing in my setup, probably your config or a plugin. Or am I misunderstanding what you mean?
eviks 5 hours ago [-]
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)
worksonmine 5 hours ago [-]
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.
eviks 5 hours ago [-]
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
worksonmine 1 hours ago [-]
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.
5 hours ago [-]
ministryofwarp 8 hours ago [-]
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.)
hou32hou 7 hours ago [-]
> 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)
ministryofwarp 7 hours ago [-]
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.
hou32hou 6 hours ago [-]
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
ministryofwarp 4 hours ago [-]
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.
rw_panic0_0 5 hours ago [-]
it's either ragebait or smth. Helix is not C++ and never would be it. Vim is C, Neovim is C++
redrobein 3 hours ago [-]
People really need to stop making analogies and saying what things really are.
pineaux 4 hours ago [-]
I agree. Helix is more like ruby on rails.
I will try ki editor
lukaslalinsky 11 hours ago [-]
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.
linsomniac 2 hours ago [-]
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.
exidex 11 hours ago [-]
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.
exidex 8 hours ago [-]
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
bulbar 7 hours ago [-]
To me, what you describe is a red flag.
For example, that doesn't sound like they will take feedback from the community serious.
exidex 7 hours ago [-]
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
hou32hou 7 hours ago [-]
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
itsn0tm3 10 hours ago [-]
There is also evil-helix [0] a helix fork with vim bindings.
Maybe that‘s something you would enjoy :)
at that point… use vim? genuinely asking. what does this get you?
lukaslalinsky 9 hours ago [-]
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.
xigoi 8 hours ago [-]
> Using neovim with plugins feels like using a rolling Linux distro, you never know what breaks next.
You can just… not update them.
GCUMstlyHarmls 6 hours ago [-]
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.
lukaslalinsky 6 hours ago [-]
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.
itsn0tm3 3 hours ago [-]
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 …
beefsack 10 hours ago [-]
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.
imjonse 7 hours ago [-]
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.
theusus 9 hours ago [-]
Using agents to edit code. And Helix doesn’t support live update of files. This is the reason it’s not my first choice.
para_parolu 46 minutes ago [-]
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.
feelamee 24 minutes ago [-]
why?
There is LSP support included. Pretty usable. Of course this is not fully IDE, but I don't expect this from "editor"
para_parolu 28 seconds ago [-]
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.
canistel 14 hours ago [-]
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...
kleiba 7 hours ago [-]
> 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:
(global-set-key (kbd "M-ESC ESC") 'keyboard-quit)
canistel 1 hours ago [-]
Thank you for mentioning this. I do have something similar...
(global-unset-key (kbd "ESC ESC ESC"))
ATMLOTTOBEER 5 hours ago [-]
Is this kind of comment not just a tautological rebuttal to any criticism of emacs
dilawar 12 hours ago [-]
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?
lorenzohess 12 hours ago [-]
Have you tried Emacs' Extensible Vi Layer ("Evil" mode)? My muscle memory switched almost seamlessly from Vim to Emacs with Evil mode
canistel 59 minutes ago [-]
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.
weinzierl 9 hours ago [-]
"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.
imjonse 7 hours ago [-]
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.
korantu 8 hours ago [-]
I think Zed editor has helix phylosophy of supporting LSP out of the box while having exact vi bindings if it is important.
It actually has Helix bindings as well which makes the investment in Helix not that risky anymore. I use both.
messh 13 minutes ago [-]
ohh Ki and Helix on the front page today... it's a good day! :)
kubafu 10 hours ago [-]
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.
marcosqanil 1 hours ago [-]
I love helix. Incredibly snappy and minimalistic but still having every feature a serious IDE needs, out of the box.
assbuttbuttass 12 minutes ago [-]
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:"
seg6 8 hours ago [-]
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'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.
buzzerbetrayed 2 hours ago [-]
I can’t believe it still doesn’t have plugins. That’s crazy. They’ve been working on that for so many years.
kristiandupont 12 hours ago [-]
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.
klibertp 6 hours ago [-]
> 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.
hou32hou 10 hours ago [-]
> For large edits, most selections will be out of the scroll window and not really helping.
> 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?
qudat 3 hours ago [-]
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.
shnpln 56 minutes ago [-]
I have been using helix for over a year now. I love it.
irusensei 2 hours ago [-]
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.
fnordlord 2 hours ago [-]
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.
g947o 2 hours ago [-]
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
rgoulter 8 hours ago [-]
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.
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.
jqbd 3 hours ago [-]
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.
dalanmiller 12 hours ago [-]
Love `hx`, vim never really clicked for me and the batteries-included nature of helix is one of its best selling points.
small_scombrus 11 hours ago [-]
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
pjmlp 9 hours ago [-]
Up voting, only because it is another native option, away from Atom started trend to ship Chrome alongside every single "modern" application.
discommentbad 2 hours ago [-]
Helix deez nuts
rrr_oh_man 10 hours ago [-]
Love the FAQ
> Post-modern?!
It's a joke. If Neovim is the modern Vim, then Helix is post-modern.
> Is it any good?
Yes.
jiehong 9 hours ago [-]
A new version should arrive this month or the next one. I think it’s worth trying it again then
vaylian 3 hours ago [-]
Cool. Any information on what will be included in the next release?
Panzerschrek 12 hours ago [-]
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.
whytevuhuni 11 hours ago [-]
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".
f311a 10 hours ago [-]
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
Panzerschrek 10 hours ago [-]
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.
homebrewer 10 hours ago [-]
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:
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.
f311a 9 hours ago [-]
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?
homebrewer 9 hours ago [-]
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
f311a 9 hours ago [-]
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.
e12e 5 hours ago [-]
If this is a concern, why not compress at the filesystem level?
small_scombrus 10 hours ago [-]
My local build of helix is 20MB, did you use the suggested flags on the install guide page?
11 hours ago [-]
raphaelmolly8 40 minutes ago [-]
[dead]
zenlot 7 hours ago [-]
[dead]
nurettin 12 hours ago [-]
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.
Rendered at 17:42:11 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
<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)
https://github.com/burke/helix/pull/1
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 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.
[0]: https://github.com/xenodium/agent-shell
[1]: https://www.youtube.com/watch?v=HJQ86HuSIJI
[2]: https://agentclientprotocol.com/get-started/clients
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
https://agentcommunicationprotocol.dev/introduction/welcome
"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.
Using it already (the granular branch) but it's far from stabilized...
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.
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 will try ki editor
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.
[0]: https://ki-editor.org/
[0]: https://github.com/martanne/vis
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.
[0] https://github.com/usagi-flow/evil-helix
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.
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:
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/
For the curious: https://github.com/seg6/dotfiles/blob/1281626127dfbf584c2939...
Would love to see some AI related plug-ins when the plug-in system is finally released.
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?
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.
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
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.
https://neovim.io/doc/user/usr_04/#_text-objects
https://github.com/nvim-mini/mini.ai
> "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.
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 think 29MB is still huge for a terminal text editor, but nevertheless not "hundreds".
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
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:
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: