Helix Editor 25.07(helix-editor.com) |
Helix Editor 25.07(helix-editor.com) |
I would definitely use it but the main disadvantage is that some keybindings work differently than vim. I understand that the keybindings may be better that the vim ones but after years of using vim I expect "x" in normal mode to delete the character under the cursor or "d" to wait for the motion before deleting anything. When this does not happen I get confused and angry. I think this would be a problem with most people that are using vim; it's very difficult to change your habits especially since you can't ever escape from vim because of its ubiquity.
Thankfully, some good people have released evil-helix, a soft fork of Helix which introduces Vim keybindings https://github.com/usagi-flow/evil-helix ; I tried it and it works great so I'll totally recommend it to people that have my problems.
As a final notice, helix (and evil-helix) works great in Windows (cmd). No need to install rust or anything. Get the .exe and you're gtg.
You can easily discard it if you can become 200% productive with better defaults on your machine. Like, do you also not use any plugins just because they aren't available on another machine?
Also the keyboard comparison doesn't work since it's not as hard to copy your editor to another machine
I'm glad to find out about evil-helix.
I want an editor with OOTB configuration and a modal editing paradigm (probably Vim's) that isn't constructed around visually synchronizing every edit action. Doing the latter means relinquishing what's good about an editing language, which is that you needn't actively think about edits so much. It's not about speed, but freeing up mental resources to think about the more interesting programming tasks at hand. Editors that demand more attention are doing a worse job.
I did edit several modal behaviours but always stick to helix logic.
Things like the multiple selections and LSP support out of the box make it super worthy, aided by its fantastic help that when you press a multi-step character it shows a little hint of possible next options, including your own custom actions.
I do on occasion need to use bare vim setups, and while some commands have been remapped in my head, I still remember enough for quick edits.
With programmability, you can have a lot more state and contextual behavior. We get this kind of fine-grained stuff in Emacs with repeat maps, transient maps, heuristic DWIM behavior, state tracking per-buffer etc.
As LLMs lower the cost of having that 8th or 9th language, you can expect programmable tools to float up in the market.
It means that it's possible to add vim support for Helix but they don't want to?
> It comes with no grammars installed and it's up to the user to install what they need ... and the grammars can be shared with other editors.
I am happy for helix but i don't think it's a good fit for me.
I use Neovim. It does what i want it to do. It's one of the best available options. But, i am not completely satisfied with it. I personally want an editor with following:
* Modern codebase. Written from scratch.
* VIM Keybindings: I have muscle memory of Vim. I would like to use Vim Keybindings in my editor. I don't want to use any other keybindings even if they are proclaimed to be better. It must walk like vim and quack like vim.
* Good defaults. I hate configuring a lot. Neovim requires configuring a lot and need not always provide good defaults if it provided. Helix might have gotten this right.
* Based on Treesitter. Better they run Treesitter parsers as a WASM in WASM runtime just like how Zed and latest Neovim do.
* Extension System. But, I don't really favor lua, js or scheme. They just aren't my cup of tea. Maybe make it a wasm module with only necessary functions exposed to it. And configuration of those plugins in non turning complete configuration language.
* TUI and optional GUI
* LSP,DAP and Snippets support built-in(along with auto complete/suggestions, UI for Testing and Debugging)
* Oil.nvim like FS as buffer built-in
* Telescope/FZF-lua style Search built-in
* Git integration built-in (Maybe magit/neogit like GIT UI is welcome)
* Flash.nvim style Treesitter based Code AST Manipulation and Jump-to by label built-in
* Macros and Multi cursors
* Optional Cursor Style AI integration (Chat UI)
Vim's inconsistent keybinds and behavior are what pushed me to Kakoune — which I find has more consistent and elegant bindings and behavior — in the first place, and Helix feels like a step backwards on that front.
And looking at the video it seems to be tui based. Nice. Gave me Emacs tui vibes.
Helix reverses bindings so that subject is first and verb is second
All the tree-sitter features and datastructures seem ideal for a query language to be bolted on - something that generalises beyond symbol search or “find all references” - guess since there’s an API this is a DSL for writing queries about your code.
Does something like this exist?
No "AI" shit pushed down your throat, and it takes the vim idea of applying actions to blocks of code, and swaps them around — you first select the code, and then apply an action to it. So you get visual feedback before doing the action and can clearly see what's going to be changed without having to spam visual mode all the time.
There was a decent article recently which explains some of the things I like in it also:
And I'm unsure what your problem is with the discussion in the ticket. I've now read the first comment (the feature request), and the last comment (the one you highlighted). Both sound totally reasonable to me.
I'm asking because I noticed slight pixel misalignments in some of the videos. For example, in the File Explorer demo, the window border isn't a solid outline—it has small gaps in the frame. I’m wondering if using a terminal like Ghostty might fix that.
You can `C` to extend the caret down, or `s` to enter a multiple regex selection. It even keeps your copied/deleted text per caret.
I do wild things with it all the time, like changing a structured document into a completely different structure.
It's powerfully expressive. IIRC, you can select a region (such as a whole file), split the selection into multiple cursors, retain only the selections which match a regex, among other things.
Understandable, for sure, but the number of users who want their own "simple" addition means it gets overwhelming pretty quickly. Helix has deferred work on most extra functionality until after implementing a Scheme extension language. Once that's done, adding features might be as simple as installing a plugin.
I respect the preferences of others but I think that most people overfit for muscle memory. I've switched OSes/editors/IDEs many times in my career. Every time, the first day or two I feel like "This is the worst fucking thing ever, I can't even type God damn it I want to set the computer on fire and become a farmer."
But... that passes. After a couple of days, I have new muscle memory and it's fine. It would be a shame to let a few days of discomfort control which software I use when software varies in its other capabilities so much more widely than just keybindings.
Now I’ve settled with Zed as desktop editor/IDE and still use vim on remotes. The context switch between a desktop app en cli is big enough that it’s never a problem. I don’t even use the vim bindings in Zed.
i respect the perspective of “i like my tools and have no reason to switch”.
what i feel is constantly missed if the understanding that your regular tools are literally one command away. learning something new doesn’t mean you can’t also take advantage of your muscle memory as necessary.
you craft an incantation that either does everything right or backfires. there’s no feedback while said incantation is being constructed.
practically, noun verb is much better of course.
Helix is strongly inspired by vim, but it is not attempting to be a drop-in replacement, and it is not possible to configure it to have the same behavior as vim with custom key-bindings because there are many things that work fundamentally differently between the two editors.
* When you press undo, and the content to be undone isn't on the screen, it will jump your screen to the relevant section (good) but also with that same keypress actually undo the content (bad). Other editors, if the content is not on the screen, will not perform the undo action unless the content is actually visible. When I press undo in Helix, I'm always taking a moment to figure out what has actually changed because of this.
* This is a conscious decision by the Helix creator, so it's unlikely to change, but undo is not granular enough. It's chunked per insert mode operation. So you could type the entirety of a tale of two cities while in insert mode, you could be in insert mode for 30 minutes, and then go back to normal mode -- at this point, if you press undo once, the entirety of what you did in insert mode is undone. There is a feature where you can explicitly give the editor a save point for undo, and you're expected to press the key manually at your desired undo points. I really don't like this at all. I have bound some keys such as spacebar to this save point, so I get more granular undo, but this has some consequences such as clearing any selections that are currently present. I couldn't figure out a way to fix this without any side effects unfortunately.
I like Helix a lot, and I have no intention of changing editors, but there are some default behaviors which I think are absolutely baffling, and the undo granularity + expectation that you manually save checkpoints for undo is one of them.
Really? What editor does this? Vim/Neovim definitely will undo the change with a single 'u' press, and every GUI editor I've ever used will undo the change immediately with a single ctrl+z.
By the way, I find this forced move rather annoying sometimes, especially when I want to jump back and forth (undo/redo) and this behavior blocks visual comparison by constantly shifting the view
How did you lose work, though, could you not redo?
But not sure real editors are as capable since some can have adverse actions on mode changes (e.g. resetting your selection or changing undo stack etc)
In fact, I have a hard time editing in web browser textareas and Google Docs because of the muscle memory of vimlike keybindings and how I've associated them with tactile keyboards. (Smartphones and tablets don't give me this problem since they feel different, but laptop/desktop Google Docs editing throws me for a loop.)
Once you learn, modal is the way to go. It feels like playing a piano over an AST. It's so elegant for code and syntax trees.
I've been using vim keybindings in vim and vimlikes (JetBrains IDEs and VS Code) for nearly twenty years now. I learned most of it within just my first three months and have picked up additional surface area every year. I would still call myself a novice relative to vim masters, but you can get a ton of value from the basic movements and chords and occasional macros. All that to say, the learning curve might look steep, but it's shallower than you think and certainly well worth it.
The only reason I'd see non-modal being useful in a modal editor is as a crunch to learn and make the onboarding smoother. But you'd probably still want the first steps to be modal anyway, so I'm not sure it would provide much value.
Just jump in. It feels weird and slow at first, but let it grow on you. It pays dividends.
Say that he is concerned about the time required for the project and only wants to safeguard the project. The post could convey the exact same message like this:
--- Alternative fictional answer by maintainer--- Confirming that code folding is a planned feature. It's a high-impact addition, but the implementation is non-trivial and requires careful design. The primary blocker is technical: our current buffer and positioning logic (see src/core/text_object.rs). A correct implementation requires a significant refactor of how we map logical buffer lines to visual screen positions.
Because core dev time is focused on xxx, a community-led effort is the most realistic path forward for this feature. I can provide review and guidance, but won't have the bandwidth to drive the implementation myself in the near term. If anybody want to contribute, Analyze the groundwork in PR #6417.
I'm keeping this issue open for high-level implementation strategies. Please take detailed design proposals to a new thread in Discussions to keep this focused. Off-topic comments will be removed. --- end of fictional answer ---
Basically, it all comes down to the vibe each response gives off. The real post is a classic "Do Not Enter" sign. The maintainer acts like the only one with the keys, essentially saying, "This is too hard for you, so don't even bother." It shuts the door on anyone who might want to help, which means the project is stuck waiting for that one person to have free time.
My rewritten version is more like leaving the door open for other smart people. The attitude is, "Look, this is a tricky problem and I'm swamped. If you're up for a real challenge, here’s the map to get started." It respects other developers' skills and invites them to be part of the solution.
I think the key to a great open-source project is that you have to actively build a team you can trust. You do that by giving people a real chance to contribute, learn the hard stuff, and eventually share the load. That's the only way a project grows beyond a one-person show and actually sticks around for the long haul.
Still, I wasn't especially impressed with "code folding is hard, we might do it one day but don't hold your breath" from an editor that purports to be a replacement for vim or neovim.
I use kakoune, because I like the client/server architecture for managing multiple windows, which helix can't do. The less configuring I do the better, but I've hardly done any in the past year. It's nice to have the option.
I do use kakoune-lsp and kak-tree-sitter.
Relevant Github comment: https://github.com/helix-editor/helix/issues/10389
I don't want or need pre-emptive visual feedback on every keystroke, because it's a tool I use every day. I want an editing language that allows me to develop a mental model of it, so that I can _avoid_ round-tripping most edit actions visually. The primary advantage of the Vi editing language has never been speed (though that tends to be a secondary one), it's that it saves you from thinking about editing. Visual feedback also adds noise; it's especially distracting when you're moving around reading code. It's not an automatic win except when you're learning. Finally, if I really need it, I'm using a modal editor! I can simply switch into visual mode for complex edits. That's the modal solution.
And in exchange for (ime, annoying) visual feedback I have to give up things like the repeat last edit '.' key, and operator pending mode (see :omap), and more... which isn't palatable to me. Of course, everyone works differently; different strokes. But it's not obviously better, in a lot of ways.
I _am_ envious of the complete default configuration Helix has. Though it seems like that's planned from Neovim in the near future, alongside multicursor (filed under 'super macros'), looking at their roadmap.
I have mixed feelings about Neovim adopting multicursor. Doesn't setting multiple cursors and then acting on them belong in the noun-verb camp? Unless you call it multivisual, of course!
People can learn to juggle plates while riding a unicycle. They can play prog rock on two-necked guitars. A handful of keybindings is like a drop in the bucket for what our nervous system is capable of encoding.
But when exploration is (temporarily at least) an end in itself, trying a new sword, moat-digging technique, or trebuchet mechanism is inherently satisfying.
the human brain can do all this and more if you let it and deal with a small amount of lag in building the neurons up
- how can you use a modal editor!?
- how can you use a nonmodal editor!?
It's not that it's difficult for me, it's that it's unnatural for me.
Different people's minds work differently.
Yep, that's precisely it.
Helix would _ideally_ like you to tell it ahead-of-time everywhere you're going to make an edit by selecting all the edit points with multiple cursors, without a great option to fire edits on the fly. Ironically I found this worse for visual feedback when making larger edits---where it's most needed---because there are usually edits happening off screen, instead of only at the point of the cursor (where the latter can be easily repeated).
It ends up feeling less interactive and more like I'm using a batch editor due to this, which (I think?) was not its intention.
But as an extremely heavy user of vim repeat and macros for the last two decades, it strikes me as a wee bit audacious to so completely dismiss its utility.
The vast majority of plugins don't fundamentally change how you interact with text.
I just tested CLion, VS Code, and Sublime Text. I thought all three behaved as described, but only CLion did. I wish it was more common though, I find it a lot more intuitive and clear on what's happening.
I likewise thought the final response linked to was great. It was straightforward and to the point.
type inference makes code waaaaaay less verbose which aids readability.
Why should anyone waste time targeting a dead use case?
The whole premise of losing productivity and spending time in the most common case to support underpowered rare use cases is deeply flawed.
It's similar to the argument for using bad defaults in config/keybinds 99% of the time just because in 1% of the time you would use another computer without your customizations.
Emacs was always modal. Emacs is inherently a modal text editor - keychords are modal, transients are modal, isearch is modal, repeat-mode is modality. The only thing the idea of vim-navigation brings on top of all that is a simple, structured and memorable language/grammar to deal with modality, that's all what it is.
Both approaches are modal; Vi just codified its modality into a more learnable, linguistic system while Emacs distributed its modality across context-sensitive mini-languages.
Emacs has this same power scattered throughout - the kill-ring, rectangle operations, keyboard macros - but Vi's genius was packaging it into a coherent, immediately graspable system that feels less like using a computer and more like speaking a concise language about text.
The best thing about learning that language is that you can apply it anywhere where keyboard input is still relevant - your browser, your terminal, your entire system - e.g. you can control your music, jump between apps, navigate between windows, etc. using only the home row keys.
I guess maybe with some configuration? A lot of emacs keybindings work out of the box in most text boxes I can think of, including this one I'm typing into right now.
If the justification about VI is that it's more learnable, then that's hardly a reason for me to switch - I've already learned emacs.
Although I do think it's a stretch to call it "immediately graspable"
Some Google Docs <=> markdown buffer as a modal editor feature (or a plugin) would be cool.
I used to use modal tiling window managers on Linux, but since window managers are always second class on Mac/Windows, that never stuck either. I bounce around too frequently for it to work. I just suffice with tmux for now.
I was pleasantly surprised to find Discord's `s/search/replace` supported as an actual feature, though having it limited to just the last message is a bit limiting.
Bro, you have no idea - vimium-c is absolutely amazing, I just can't really imagine my life without it. Toggling tab pinning and muting, moving tabs, grouping tabs, quickly finding a tab, extracting a tab into a window, joining windows, etc. - if you even try doing all that without modality, you'd have to keep learning new keybindings and memorize them.
The worst part of that is that keybindings would change. For me - font size change on a browser page works the same way as in my editor, and the terminal, and it is the same in every browser that vimium supports.
You basically need to ask yourself if you really want to keep learning and memorizing various, sometimes absolutely unrelated and difficult to reach key bindings that almost invariably require you holding modifiers, sometimes wasting your mental energy on subtleties between ctrl/alt/cmd/shift+key or you'd rather sit down, spend some time and take a systematic approach that will make your life so much easier.
> window managers are always second class on Mac/Windows, that never stuck either.
I don't use Windows much, but Yabai for Mac is really good. I've procrastinated on trying it for a long time, when I finally tried, it took me literally fifteen minutes to start. Then I hooked up my Hammerspoon config and added some key bindings. I'm very happy about it. Like for example, I've been so annoyed by Zoom that always scatters its windows around all my monitors, now I have "group Zoom windows" feature, and it's really nice.
Most people think of keyboard input as a linear, one-dimensional approach to text editing, that's what you're doing here. Vim-style navigation offers something fundamentally different - a spatial "language" that maps directly to how we conceptualize our workspace.
Consider window management in vanilla Emacs:
- C-x 2 splits horizontally (mnemonic: "two windows")
- C-x 3 splits vertically (less intuitive—why 3?)
- C-x 4 becomes a prefix for file operations in other windows
The logic breaks down quickly. There's no consistent mental model connecting these commands. C-x 4 abandons the splitting metaphor entirely, becoming a namespace for "other window" operations rather than a window count.
Doom Emacs's vim-inspired approach creates a coherent spatial language:
- SPC w s - split
- SPC w v - vertical split
- SPC w h/j/k/l - jump left/down/up/right
The hjkl directional keys mirror vim's movement commands, creating a consistent spatial metaphor. Your fingers learn to "think" in terms of physical direction rather than arbitrary key combinations.
This spatial approach transforms window management from memorizing disconnected shortcuts into developing spatial intuition. Instead of thinking "what was that split command again?", you think "I want to move right" and your fingers naturally press 'h'. The keybindings become an extension of spatial reasoning rather than abstract symbol manipulation.
This principle extends beyond window management - vim's entire philosophy treats text editing as navigation through dimensional space, making complex operations feel natural and memorable.
And like I said, this model can easily be extended beyond just the text editor - you can navigate things in your browser, terminal, etc. Why would I even try to learn and memorize new keyboard shortcuts e.g., every time I install a new music player? I can control volume with j/k and previous/next song with h/l in any music player.
> I do think it's a stretch to call it "immediately graspable"
But it is though. It is very simple grammar. Anyone who's not mentally deficient can understand and learn it quickly. Building the muscle memory takes time, yes, but the idea itself is absolutely graspable. I remember, I hated myself for about a week. After that, my keyboard life was never the same.
And yes. Complaining about 100mb nowadays is ridiculous. You probably have larger logfiles sitting somewhere in disk doing nothing right now, regardless of your OS.
And those log files can be easily wiped or rotated (i.e. compressed, which can greatly reduce their size), as they should. You do not do the same with your other files, do you?
141MB: emacs-30.1-nodeps.zip
75MB: emacs-30.1-installer.exe (better compression? Contents seem similar)
27MB helix-25.07-x86_64-windows.zip
So there's still an Emacs distinction, it seems
(*not that these size differences matter in practice -- helix's "bulk" is all in compiled language grammars, each of which is not loaded unless you use the language.)
But regardless, if someone were to only ever installing Helix on their system, you might have a point. But you probably want to install many applications and if every applications starts wasting storage, you will soon run out of space.
But for desktop use, I think it's a good default to have everything "just work" out-of-the-box, because 110mb is nothing for typical developer machines.
Out of curiosity, what hardware are you picturing those people running it on?
I've run Helix on a Daylight computer, which has a deliberately underpowered CPU (MediaTek Helio G99) and it's incredibly fast/snappy. 110mb is still near-trivial on the 128GB storage.
If you're (validly) worried about bloated software, note that Alpine's helix package is 10.3MB, which is smaller than their Neovim or Emacs packages. Individual language files are small (python is ~500kb uncompressed), there are just hundreds of supported languages. But installed ones are not loaded unless you edit the language.
As someone mentioned, Emacs is over 100 MB, so it does not have to be hypothetical. That said, I use emacs (and vim) interchangeably and I have nothing against it. I have LibreOffice, too, which is also a behemoth, but so is Haskell with its modules that I see getting updated regularly. In any case, I still prefer KISS and the fewer bloat as possible.
Alpine package sizes:
- helix 10.3MiB (+ 3 dependencies: musl, libgcc, sh)
- emacs 14.5MiB (+ 1 dependency: musl)
- neovim 18.7MiB (+ 9 dependencies musl, lua, tree-sitter, libint, libluv, unibilium, utf8proc, libuv, libluajit))
So it doesn't seem out of the ordinary for popular cli editors, if you're worried about smaller environments.