Helix is great and includes a lot of stuff out of the box (file pickers, syntax highlighting, linting etc) without any configuration or installing plugins (contrary to vim or neovim).
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.
For me, the issue isn't that I'm unwilling to learn new things. It's that I cannot use these keybindings anywhere else. Almost all online editors and workstations have some sort of vim keybindings. When I ssh into a Linux machine I can trust it has vim editor. It's like qwerty keyboard, I'm sure that there's better layouts but I just cannot discard the flexibility of being able to jump on most machines and be 99% productive almost instantly.
> I just cannot discard the flexibility of being able to jump on most machines and be 99% productive almost instantly.
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
Honestly, I don't think this is a big deal. I use helix as my primary editor, but when I'm on another machine and it only has vi or whatever I just use that and I can mentally switch to using the vim keybinds with little issue. Like sometimes I'll mistakenly `m-i-w-c` instead of `c-i-w` or `d` instead of `x`, but then I just hit `u` and continue.
i didn't find it to be a big issue because helix doesn't have different key bindings as much as it simply has a reverse grammar. If you think of vim as a language to manipulate text objects (which is what it is basically) everything is verb-noun, in helix it's noun-verb. There's a few idiosyncrasies but approaching it that way I got around pretty much immediately.
I'm totally fine with (re)learning new tools, but having given Helix a solid try found the noun-verb model worse; the visual feedback is fun but distracting, particularly when you're moving around reading code. For it you give up things like repeating edits easily (bound as '.' in Vim). There's also a statefulness to Helix's model that isn't present in Vim; whereas in the latter I only have to care about where I _am_ in the file as I'm making my edit, in Helix I have to care about where I've _been_ because that dictates what I've currently got selected. See my other comment for details.
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.
Yes, its model is that you make a selection and then act on it. After the action happens there's nothing selected. The editor can't infer your intent in making the selection, so there's no reasonable notion of repeating the last edit. You can separately repeat the last motion or last action, but not the whole edit---which of course isn't as useful.
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.
The existence of a repeat or “magic” key is one of the more interesting developments alternative keyboard layouts designs. The use case is slightly different of course.
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.
As someone who used vim (and then neovim) for some two decades, I didn’t find it hard to adapt to helix, and now vastly prefer it.
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.
Helix is adding a Scheme for programmable configuration.
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.
This is where vim keybinds fall short every time. I do appreciate the effort, and have zero expectations about a one to one match, but the moment I do something out of habit and an editor doesn’t do what I expect, in “vim mode”, it breaks the illusion.
I love Helix, I highly recommend it to anyone who never quite got on board with vim but likes the idea of it. I found it much easier to learn and use, and it is distinguished from other vimlikes in that it's got a useful starting configuration.
I really really like it. I honestly think they should wrap it in a GUI with some conveniences like a mouse based file browser and it can compete well with vscode.
Have you found them to work well and be consistent? I've been a helix user for a couple years now, and I found Zed's helix keybindings to be inaccurate. Either that or I have some config options set that were confounding them. Curious how your experience with them has been?
Same. Or — just an idea — maybe it is time to kickstart an adapter so that we can plug a 386 into a LGA 1700 socket? A little underclocking, instruction translation, voltage conversion and presto.
The editor is 10mb. It's the grammar files that are represent the bulk, and those are optional.
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.
I know, I was talking about a hypothetical text editor being 100 MB (without grammar files).
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?
Why the down-vote? You don't rotate your logs? Thought it is commonplace. Rotating logs includes compressing old ones. Or are your log files actually over 100 MB? Why? What are you printing? Output of "yes"? :D
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.
Long forgotten the times back in the days during the Great Editor Wars when Emacs was shunned as an acronym for "Eight Megabytes And Constantly Swapping". The youth of today ...
(*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.)
I mean a base Mac Mini in 2025 comes with 256GB of storage. Some storage is still damn expensive.
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.
Almost all the size is language grammars, which are optional and removable. Some distros like Alpine make them separate packages.
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.
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
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.
But there is only so much room for muscle memory or context to switch between. I tried Helix for a while, got used to it and I really liked it, especially the noun verb order being different from vim. Seeing what you have selected before performing the action. But for me the problem is that vim is everywhere I go or will eventually end up. All my servers have vim. Every server I need to randomly debug has vim or vi. So my muscle memory for vim keeps getting refreshed as well. And switching between the two constantly is just a pain. I could take along Helix to all these servers. But that is not practical nor do I need all the features Helix uses. Or I would miss specific feature which I then also have to bring along.
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.
> But there is only so much room for muscle memory or context to switch between.
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.
Fear and doubt are mighty enemies. “Did I make the right choice?” haunts us all.
But when exploration is (temporarily at least) an end in itself, trying a new sword, moat-digging technique, or trebuchet mechanism is inherently satisfying.
i know many very smart people that insist that their muscle memory makes it impossible to switch editors or shells.
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.
I think noun-verb is worse; I'm unsure where the idea comes from that Helix's (or Kakoune's) editing model is better. Bear with my short rant. :-)
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!
damn. noun verb makes spell casting visually noisy and... as if you didn't know your spells and havent yet adopted 100% typing accuracy --- the feedback (visual noise) just makes you weak anyways. just `u` and helix inherently loses `.`
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.
Its keybindings aren't identical to vim. They're very similar in many places, but are also different in quite common things like deleting lines etc. (dd vs xd)
It's a soft fork trying to catch up with the main codebase. It feels like a second class citizen. Features introduced in Helix might not be intended for usage with vim keybindings anyway.
Love Helix. Congrats. Good looking default theme. Sensible defaults. Literally install and use, no configuration needed. Well I haven't replaced my IDE with it , but set alias of vi to it and made it as $EDITOR for all quick cli edits. So now whenever I need to do quick debugging edits in k9s, it calls for Helix.
I'd love for Helix to implement a "Kakoune mode". I develop on Windows at work, where Kakoune is not ideal, so Helix seems like it'd be a perfect fit, except I can't get over the keybindings. Its keybinding philosophy encourages verbosity instead of Kakoune's terseness, which bothers me more than it probably should, and as far as I can tell its keymap configuration isn't yet powerful enough to emulate Kakoune well.
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.
I really wanted to like Helix, and for the most part did, but there is something about the way undo works that just feels incredibly wrong to me. What it wants to undo doesn't always seem logical and always undoes too much. I've lost work because of it in the past.
There are two things that consciously bug me about undo,
* 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.
What happens if you can't fit all changes into one screen? Does it jump to a random /last edit but undoes all the changes?
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
> Other editors, if the content is not on the screen, will not perform the undo action unless the content is actually visible.
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.
Ah, thanks for the correction. I'm wrong on how common this is.
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.
Just tried Goland and it works the way you describe. Emacs is immediate restore.
CLion and Goland are both JetBrains IDEs, so no surprise they use the same mechanism. FWIW, I like it and think it's preferable.
Huh, that's interesting. I've only used VSCode and Sublime, never CLion. I'm honestly not sure how I'd feel going the other way, but I could see the behavior being annoying if you're not expecting it.
I think I panicked at the amount it has undone and then in my attempt to redo, made a change and got myself into a mess with the history. It was quite early on in my time with it.
Very detailed explanations. I learned a bunch about the syntax highlighting and code understanding in Helix & friends just from reading this.
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.
I'm a long time Vim user, and I really liked Helix when I tried it last year. On one hand, I very much like the cleanliness of the whole project. On the other hand, I'm one of those people who find AI assisted coding useful (not vibe coding, just auto complete, auto edit suggestion, possibility to select block and make it do change on it). This is why I eventually started to move to VS Code with Cody, despite being way more comfortable in modal editors.
I terribly need a vim-like with Helix all-in-one comprehensiveness. Neovim distributions are too loosely coupled and always have some odd sharp edge. Vim and its interfaces needs some rethinking anyway, but keep Action-Object modal orientation.
Yeah that's not a good way of describing, its more like Verb-Direction-Subject, e.g. `d3f(` means "delete up to the 3rd opening paren"; `2f.` means "move cursor to the 2nd found '.' character"; but there are exceptions when the subject is implicit, like `5j` means "Move down 5 physical lines".
Helix reverses bindings so that subject is first and verb is second
Been using helix for over a year (mostly Elixir development) after a decade of (neo)vim, very happy so far! My config file is like 10 lines long :D
Congrats on the release!
Helix is the most interesting editor I've seen in a while. Very sane configuration — my config includes just one line to change the default theme to something with more contrast.
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:
It looks very interesting and I'd love to support it, but editors that must be modal are difficult for me to use, personally. Editors that are not modal can be made modal, but can modal editors be made non-modal?
Have you ever used a modal editor? It takes the smallest bit of brain training to adapt, but feels more logical for long form coding. I spend a lot more time reading code than writing. Having more tools to grep/highlight/move text in one mode is quite productive.
Oh, wow. I really enjoy modal editors, especially the Kakoune model seen in Helix and meow-mode for Emacs but I could never put it into words why I actually preferred them.
I went from vim to emacs and used that for a few years, then moved to VS Code for the next 10 years or so. It's showing its age a bit lately, so I'm sure I'll try another one soon, which is why I looked at Helix. But I'm very glad there are very different editors for very different types of minds, just like how there are different ways to indent/format code. Programmers do not have one-size-fits-all minds, and we shouldn't design anything assuming they do/should. (Looking at you, Golang.)
Modal editors can be (in principle) made non-modal by changing keybinds to combos that change modes behind your back, so you'll keep insert mode as your primary one. So strictly speaking, non-modal editors are the ones that force you into only one style
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)
Sure, you can leave it in insert mode the entire time. I'm not sure that's really what you want though, as you'd effectively turn the editor into a basic notepad app.
Probably not, but there are many editors to choose from if you do not like it. Some people prefer just modal so editors like vim/helix/etc. are tailor-made for them.
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.
I think it really does come down to taste. I learned how to do modal text editing. I believe it is a fine and efficient way to edit. So is non-modal. So is mouse editing. I still prefer the emacs way of doing things
This, though I've always found the Chrome/Firefox vimlike browser plugins to be such second class citizens that they've never stuck with me.
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.
My comment was after having learned and gotten very good at vim about 15 years ago and used it primarily (via neovim) for at least a while, probably a few years, before moving to emacs, and finally VS Code. I still use vim for quick edits on the command line. I know how to edit modally, it just feels unnatural for me.
This is great. I have been daily driving Helix for a few years now and every release has been really exciting. Still anxiously waiting on a plugin system, but that’s more of a bonus than a need.
I love the example with git blame for the current line. Helix is my daily driver alongside lazygit, however I much appreciate a tighter integration of Git in Helix. A colleague showed me what he can do with magit in emacs, and that was some next-level stuff (e.g. cycling the buffer through the Git history of the file). Previously I was using Neovim, but I'm really happy with my switch to Helix. So much less config, keybindings I find more intuitive and multi-cursor editing. For agentic coding I'm looking into Aider and OpenCode. I expect a tool like that to join my terminal setup with Helix and lazygit.
Great editor, switched from neovim and can't get enough of it. The software where I really exited about new releases. No issues for me, and only good vibes ahead. Thanks devs
Injections / nested tree-sitter scopes is neat. I guess this means it can highlight html template code where html, js, css and the template syntax all have highlights?
Here is the forum post that convinced me NOT to continue getting into Helix. It says all I need about the project health. And given the development since then, I am more confident that it’s a bad horse to bet on.
https://github.com/helix-editor/helix/issues/1840#issuecomme...
I don't see the problem. It's a great result: (paraphrasing) "people arguing about whether code folding is useful or not is pointless. we're going to do it eventually but not right now." What's wrong with that?
I wasn't especially impressed with "code folding is hard, we might do it one day but don't hold your breath", especially from an editor that purports to be a replacement for vim/neovim.
What's so bad about this? I skimmed through it and it seems like it was handled quite well. Curious what you're learning from it about the project health.
I've never used Helix and I likely never will, so I've got no horse in this race. But code folding, seriously? I'd be totally against it. It's yet another editor feature that ties your source code to tooling. It allows you to write too large and too many functions, while keeping the code readable to yourself. Source code should be readable (mostly) independently of tooling. It should be readable when printed to paper. (This is also why type inference in languages that aren't inherently functional languages is incredibly stupid; I understand that the compiler can infer the type under "auto", but now, when reviewing the code, I too must. Who the fuck wants that, seriously.)
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.
Could not agree more with everything you said. I hate code folding because it leads to giant functions and blocks that are way too big, but because of the folding people don't have to look at it and scroll (which if they did, they would be much less inclined to write and ship such shit in the first place). Same with type inference. It's almost no effort to write out the type, and it's eminently readable. With type inference, it's not at all obvious. I usually get "well you can just hover over it with the IDE and it will tell you the type." I don't want to have to hover over stuff just to see the type! Not only is that a major downgrade from the previous state where it was just "String some_str" or whatever, but having to pause and grab the mouse and move it over to the variable is majorly disruptive to reading and requires me to use a mouse (which I don't normally use). Also, I use neovim, not whatever IDE you use and think everyone else must use.
I likewise thought the final response linked to was great. It was straightforward and to the point.
Web page can run (and some code-focused pages do) code folding code, so the question is still relevant with minor modification.
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.
Does anyone know which terminal is being used in the screencast?
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.
They're actually not videos! They're using asciinema: https://asciinema.org/, which is rendering actual text in the webpage - try selecting some while the recording is playing.
The file explorer is something I’ve been really wanting. But I really want to be able to quickly create, rename, delete the way I can in netrw. I use netrw like this all the time.
Indeed. Helix's multi-cursor support seems like a rocket-powered chainsaw to me.
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.
Authors are free to do as they please, but as an entitled member of the peanut gallery…aren’t there already enough small configuration languages? Seems like a distraction when there are already hundreds of schemes, Lua, Janet, etc.
In that case, Kakoune[1] (Helix’s main inspiration) is probably more your jam. You get an RPC interface and are free to script it from anything you want (shell to Rust is about the range I’ve encountered). It does mean that you don’t get the batteries you get with Helix (e.g. LSP support) and need to bring your own (e.g. kakoune-lsp[2]).
Is including batteries the main reason helix seems to have started taking off, while kakoune hasn't?
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.
Helix is great and includes a lot of stuff out of the box (file pickers, syntax highlighting, linting etc) without any configuration or installing plugins (contrary to vim or neovim).
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.
For me, the issue isn't that I'm unwilling to learn new things. It's that I cannot use these keybindings anywhere else. Almost all online editors and workstations have some sort of vim keybindings. When I ssh into a Linux machine I can trust it has vim editor. It's like qwerty keyboard, I'm sure that there's better layouts but I just cannot discard the flexibility of being able to jump on most machines and be 99% productive almost instantly.
> I just cannot discard the flexibility of being able to jump on most machines and be 99% productive almost instantly.
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
> do you also not use any plugins just because they aren't available on another machine?
The vast majority of plugins don't fundamentally change how you interact with text.
So? Narrow it down to the most useful minority that do, the question still remains
Honestly, I don't think this is a big deal. I use helix as my primary editor, but when I'm on another machine and it only has vi or whatever I just use that and I can mentally switch to using the vim keybinds with little issue. Like sometimes I'll mistakenly `m-i-w-c` instead of `c-i-w` or `d` instead of `x`, but then I just hit `u` and continue.
I know right
To anti-pile-on to the other replies - this is exactly why I haven't given it much of a spin.
I'm glad to find out about evil-helix.
i didn't find it to be a big issue because helix doesn't have different key bindings as much as it simply has a reverse grammar. If you think of vim as a language to manipulate text objects (which is what it is basically) everything is verb-noun, in helix it's noun-verb. There's a few idiosyncrasies but approaching it that way I got around pretty much immediately.
I'm totally fine with (re)learning new tools, but having given Helix a solid try found the noun-verb model worse; the visual feedback is fun but distracting, particularly when you're moving around reading code. For it you give up things like repeating edits easily (bound as '.' in Vim). There's also a statefulness to Helix's model that isn't present in Vim; whereas in the latter I only have to care about where I _am_ in the file as I'm making my edit, in Helix I have to care about where I've _been_ because that dictates what I've currently got selected. See my other comment for details.
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.
surprised helix doesn't support the . key - is that incompatible with its interaction model somehow?
Yes, its model is that you make a selection and then act on it. After the action happens there's nothing selected. The editor can't infer your intent in making the selection, so there's no reasonable notion of repeating the last edit. You can separately repeat the last motion or last action, but not the whole edit---which of course isn't as useful.
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.
Hmm
The existence of a repeat or “magic” key is one of the more interesting developments alternative keyboard layouts designs. The use case is slightly different of course.
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.
As someone who used vim (and then neovim) for some two decades, I didn’t find it hard to adapt to helix, and now vastly prefer it.
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.
Helix is adding a Scheme for programmable configuration.
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.
Omg. Vim keybindings is the single blocker for me to try helix.
It means that it's possible to add vim support for Helix but they don't want to?
Sure, why wouldn’t it be? Plenty of programs have Vim keybindings. The challenge is matching the behavior perfectly 1-1.
This is where vim keybinds fall short every time. I do appreciate the effort, and have zero expectations about a one to one match, but the moment I do something out of habit and an editor doesn’t do what I expect, in “vim mode”, it breaks the illusion.
Same same.
I love Helix, I highly recommend it to anyone who never quite got on board with vim but likes the idea of it. I found it much easier to learn and use, and it is distinguished from other vimlikes in that it's got a useful starting configuration.
I really really like it. I honestly think they should wrap it in a GUI with some conveniences like a mouse based file browser and it can compete well with vscode.
Zed has Helix keybindings now!
https://zed.dev/
Not quite yet ...
https://github.com/zed-industries/zed/discussions/33580
Have you found them to work well and be consistent? I've been a helix user for a couple years now, and I found Zed's helix keybindings to be inaccurate. Either that or I have some config options set that were confounding them. Curious how your experience with them has been?
Life is to short to learn and memorize Vi / Helix keybinds. That's why I stay with Micro as terminal editor.
Very nice to see a text editor that is very capable, yet still minimal and not focused on including a bunch of useless AI features.
> minimal
https://github.com/helix-editor/helix/issues/6187
I agree. I can't fit this on my hard drive. I've had this 386 for 30 years. Why should I have to upgrade it just for some text editor?
Same. Or — just an idea — maybe it is time to kickstart an adapter so that we can plug a 386 into a LGA 1700 socket? A little underclocking, instruction translation, voltage conversion and presto.
111mb is bloat apparently in a time where storage is in the terabytes.
111 MB for a text editor is acceptable? I mean I get it, "we" are getting conditioned to it, but...
The editor is 10mb. It's the grammar files that are represent the bulk, and those are optional.
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 it’s a 10MB static binary I can just drop into ~/.local/bin and have Just Work(tm)
I know, I was talking about a hypothetical text editor being 100 MB (without grammar files).
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?
Why the down-vote? You don't rotate your logs? Thought it is commonplace. Rotating logs includes compressing old ones. Or are your log files actually over 100 MB? Why? What are you printing? Output of "yes"? :D
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.
Long forgotten the times back in the days during the Great Editor Wars when Emacs was shunned as an acronym for "Eight Megabytes And Constantly Swapping". The youth of today ...
Emacs binary download page pointed me to Windows, but for comparison:
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.)
(replying to myself)
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.
I am old enough to remember that. :D
I mean a base Mac Mini in 2025 comes with 256GB of storage. Some storage is still damn expensive.
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.
Yes, but 111MB is .04% of 256GB. Install a hundred such "wasteful" apps and you're up to a whole 4% of that storage.
Almost all the size is language grammars, which are optional and removable. Some distros like Alpine make them separate packages.
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.
Have you considered that professional developers who can afford expensive computers are not the only ones using a text editor?
Do correct me if I'm wrong, but aren't grammar files optional?
> As an example, here's the official Alpine package: https://pkgs.alpinelinux.org/package/edge/community/x86_64/h...
> 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.
Congrats!
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)
> I have muscle memory of Vim.
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.
But there is only so much room for muscle memory or context to switch between. I tried Helix for a while, got used to it and I really liked it, especially the noun verb order being different from vim. Seeing what you have selected before performing the action. But for me the problem is that vim is everywhere I go or will eventually end up. All my servers have vim. Every server I need to randomly debug has vim or vi. So my muscle memory for vim keeps getting refreshed as well. And switching between the two constantly is just a pain. I could take along Helix to all these servers. But that is not practical nor do I need all the features Helix uses. Or I would miss specific feature which I then also have to bring along.
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.
> But there is only so much room for muscle memory or context to switch between.
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.
Fear and doubt are mighty enemies. “Did I make the right choice?” haunts us all.
But when exploration is (temporarily at least) an end in itself, trying a new sword, moat-digging technique, or trebuchet mechanism is inherently satisfying.
i know many very smart people that insist that their muscle memory makes it impossible to switch editors or shells.
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.
personally i just find verb noun editing a tiny bit more fun than noun verb.
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.
I think noun-verb is worse; I'm unsure where the idea comes from that Helix's (or Kakoune's) editing model is better. Bear with my short rant. :-)
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 strongly agree.
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!
damn. noun verb makes spell casting visually noisy and... as if you didn't know your spells and havent yet adopted 100% typing accuracy --- the feedback (visual noise) just makes you weak anyways. just `u` and helix inherently loses `.`
>list of requirements So basically Neovim, but swapping out Lua for something else.
Its not very clear to me which of these Helix hasnt hit. To me it looks like Helix is very close to what you are looking for.
* VIM Keybindings: I have muscle memory of Vim.
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.
Only extension system, but honestly I've never missed it in 3y of usage coming from nvim.
vim keybinding. helix doesn't have vim keybindings. it might or might not be better but it isn't vim keybinding.
Its keybindings aren't identical to vim. They're very similar in many places, but are also different in quite common things like deleting lines etc. (dd vs xd)
FYI (for OP): check this fork out https://github.com/usagi-flow/evil-helix
It's a soft fork trying to catch up with the main codebase. It feels like a second class citizen. Features introduced in Helix might not be intended for usage with vim keybindings anyway.
Love Helix. Congrats. Good looking default theme. Sensible defaults. Literally install and use, no configuration needed. Well I haven't replaced my IDE with it , but set alias of vi to it and made it as $EDITOR for all quick cli edits. So now whenever I need to do quick debugging edits in k9s, it calls for Helix.
I'd love for Helix to implement a "Kakoune mode". I develop on Windows at work, where Kakoune is not ideal, so Helix seems like it'd be a perfect fit, except I can't get over the keybindings. Its keybinding philosophy encourages verbosity instead of Kakoune's terseness, which bothers me more than it probably should, and as far as I can tell its keymap configuration isn't yet powerful enough to emulate Kakoune well.
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.
I really wanted to like Helix, and for the most part did, but there is something about the way undo works that just feels incredibly wrong to me. What it wants to undo doesn't always seem logical and always undoes too much. I've lost work because of it in the past.
There are two things that consciously bug me about undo,
* 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.
What happens if you can't fit all changes into one screen? Does it jump to a random /last edit but undoes all the changes?
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
> Other editors, if the content is not on the screen, will not perform the undo action unless the content is actually visible.
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.
Ah, thanks for the correction. I'm wrong on how common this is.
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.
Just tried Goland and it works the way you describe. Emacs is immediate restore. CLion and Goland are both JetBrains IDEs, so no surprise they use the same mechanism. FWIW, I like it and think it's preferable.
Huh, that's interesting. I've only used VSCode and Sublime, never CLion. I'm honestly not sure how I'd feel going the other way, but I could see the behavior being annoying if you're not expecting it.
I agree the undo is sometimes a bit weird, as is the “repeat last command”. However, the rest of it is so nice that I keep Helix as my main editor.
How did you lose work, though, could you not redo?
I think I panicked at the amount it has undone and then in my attempt to redo, made a change and got myself into a mess with the history. It was quite early on in my time with it.
Very detailed explanations. I learned a bunch about the syntax highlighting and code understanding in Helix & friends just from reading this.
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?
zed uses tree-sitter and has a powerful query engine (dsl is lisp scheme): https://zed.dev/blog/syntax-aware-editing#tree-queries
Does zed have anything like the 'locals' query that Helix has added in this version, according to TFA?
Heh. A "post-modern" editor. The second best joke since Fish's "Finally a command line shell for the 90s".
And looking at the video it seems to be tui based. Nice. Gave me Emacs tui vibes.
I'm a long time Vim user, and I really liked Helix when I tried it last year. On one hand, I very much like the cleanliness of the whole project. On the other hand, I'm one of those people who find AI assisted coding useful (not vibe coding, just auto complete, auto edit suggestion, possibility to select block and make it do change on it). This is why I eventually started to move to VS Code with Cody, despite being way more comfortable in modal editors.
I terribly need a vim-like with Helix all-in-one comprehensiveness. Neovim distributions are too loosely coupled and always have some odd sharp edge. Vim and its interfaces needs some rethinking anyway, but keep Action-Object modal orientation.
Maybe Evil-Helix[0] is what's called for. Still seems like it has lots of edges.
[0]https://github.com/usagi-flow/evil-helix
What is Action-Object modal orientation?
Yeah that's not a good way of describing, its more like Verb-Direction-Subject, e.g. `d3f(` means "delete up to the 3rd opening paren"; `2f.` means "move cursor to the 2nd found '.' character"; but there are exceptions when the subject is implicit, like `5j` means "Move down 5 physical lines".
Helix reverses bindings so that subject is first and verb is second
Been using helix for over a year (mostly Elixir development) after a decade of (neo)vim, very happy so far! My config file is like 10 lines long :D Congrats on the release!
Helix is the most interesting editor I've seen in a while. Very sane configuration — my config includes just one line to change the default theme to something with more contrast.
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:
https://herecomesthemoon.net/2025/06/i-like-helix/
It looks very interesting and I'd love to support it, but editors that must be modal are difficult for me to use, personally. Editors that are not modal can be made modal, but can modal editors be made non-modal?
Have you ever used a modal editor? It takes the smallest bit of brain training to adapt, but feels more logical for long form coding. I spend a lot more time reading code than writing. Having more tools to grep/highlight/move text in one mode is quite productive.
People who give vim some time split in two camps:
- how can you use a modal editor!?
- how can you use a nonmodal editor!?
Oh, wow. I really enjoy modal editors, especially the Kakoune model seen in Helix and meow-mode for Emacs but I could never put it into words why I actually preferred them.
Yep, that's precisely it.
I used vim for a few years about 15 years ago, yes.
It's not that it's difficult for me, it's that it's unnatural for me.
Different people's minds work differently.
It is wild to me that you could use vim for years and not like the modal style. To each their own, I would have bounced to emacs.
I went from vim to emacs and used that for a few years, then moved to VS Code for the next 10 years or so. It's showing its age a bit lately, so I'm sure I'll try another one soon, which is why I looked at Helix. But I'm very glad there are very different editors for very different types of minds, just like how there are different ways to indent/format code. Programmers do not have one-size-fits-all minds, and we shouldn't design anything assuming they do/should. (Looking at you, Golang.)
Modal editors can be (in principle) made non-modal by changing keybinds to combos that change modes behind your back, so you'll keep insert mode as your primary one. So strictly speaking, non-modal editors are the ones that force you into only one style
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)
Sure, you can leave it in insert mode the entire time. I'm not sure that's really what you want though, as you'd effectively turn the editor into a basic notepad app.
Probably not, but there are many editors to choose from if you do not like it. Some people prefer just modal so editors like vim/helix/etc. are tailor-made for them.
I wouldn't want to go from modal to non-modal.
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.
I think it really does come down to taste. I learned how to do modal text editing. I believe it is a fine and efficient way to edit. So is non-modal. So is mouse editing. I still prefer the emacs way of doing things
And then you start craving modal interfaces in your browser, file manager, terminal, messenger...
Some Google Docs <=> markdown buffer as a modal editor feature (or a plugin) would be cool.
This, though I've always found the Chrome/Firefox vimlike browser plugins to be such second class citizens that they've never stuck with me.
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.
I've had a good experience with Tridactyl on Firefox, but yeah, definitely second class citizens.
My comment was after having learned and gotten very good at vim about 15 years ago and used it primarily (via neovim) for at least a while, probably a few years, before moving to emacs, and finally VS Code. I still use vim for quick edits on the command line. I know how to edit modally, it just feels unnatural for me.
This is great. I have been daily driving Helix for a few years now and every release has been really exciting. Still anxiously waiting on a plugin system, but that’s more of a bonus than a need.
I love the example with git blame for the current line. Helix is my daily driver alongside lazygit, however I much appreciate a tighter integration of Git in Helix. A colleague showed me what he can do with magit in emacs, and that was some next-level stuff (e.g. cycling the buffer through the Git history of the file). Previously I was using Neovim, but I'm really happy with my switch to Helix. So much less config, keybindings I find more intuitive and multi-cursor editing. For agentic coding I'm looking into Aider and OpenCode. I expect a tool like that to join my terminal setup with Helix and lazygit.
Great editor, switched from neovim and can't get enough of it. The software where I really exited about new releases. No issues for me, and only good vibes ahead. Thanks devs
Injections / nested tree-sitter scopes is neat. I guess this means it can highlight html template code where html, js, css and the template syntax all have highlights?
Does it do code folding yet?
Here is the forum post that convinced me NOT to continue getting into Helix. It says all I need about the project health. And given the development since then, I am more confident that it’s a bad horse to bet on. https://github.com/helix-editor/helix/issues/1840#issuecomme...
I don't see the problem. It's a great result: (paraphrasing) "people arguing about whether code folding is useful or not is pointless. we're going to do it eventually but not right now." What's wrong with that?
I wasn't especially impressed with "code folding is hard, we might do it one day but don't hold your breath", especially from an editor that purports to be a replacement for vim/neovim.
What's so bad about this? I skimmed through it and it seems like it was handled quite well. Curious what you're learning from it about the project health.
I've never used Helix and I likely never will, so I've got no horse in this race. But code folding, seriously? I'd be totally against it. It's yet another editor feature that ties your source code to tooling. It allows you to write too large and too many functions, while keeping the code readable to yourself. Source code should be readable (mostly) independently of tooling. It should be readable when printed to paper. (This is also why type inference in languages that aren't inherently functional languages is incredibly stupid; I understand that the compiler can infer the type under "auto", but now, when reviewing the code, I too must. Who the fuck wants that, seriously.)
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.
Could not agree more with everything you said. I hate code folding because it leads to giant functions and blocks that are way too big, but because of the folding people don't have to look at it and scroll (which if they did, they would be much less inclined to write and ship such shit in the first place). Same with type inference. It's almost no effort to write out the type, and it's eminently readable. With type inference, it's not at all obvious. I usually get "well you can just hover over it with the IDE and it will tell you the type." I don't want to have to hover over stuff just to see the type! Not only is that a major downgrade from the previous state where it was just "String some_str" or whatever, but having to pause and grab the mouse and move it over to the variable is majorly disruptive to reading and requires me to use a mouse (which I don't normally use). Also, I use neovim, not whatever IDE you use and think everyone else must use.
I likewise thought the final response linked to was great. It was straightforward and to the point.
> It should be readable when printed to paper.
Why should anyone waste time targeting a dead use case?
Right. But if we replace 'paper' with 'webpage' the parent post is still relevant.
Web page can run (and some code-focused pages do) code folding code, so the question is still relevant with minor modification.
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.
Not yet.
Does anyone know which terminal is being used in the screencast?
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.
They're actually not videos! They're using asciinema: https://asciinema.org/, which is rendering actual text in the webpage - try selecting some while the recording is playing.
The file explorer is something I’ve been really wanting. But I really want to be able to quickly create, rename, delete the way I can in netrw. I use netrw like this all the time.
Looking forward to the new file picker! Now to wait for evilhelix (https://github.com/usagi-flow/evil-helix) to sync with upstream
Very sad that Helix still doesn't have Sublime-like multi-caret support. All I want is to Ctrl + Click and Shift + Alt + Arrows.
Multi-caret support in Helix is awesome. It’s even the first feature they mention on the homepage.
https://helix-editor.com
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.
Indeed. Helix's multi-cursor support seems like a rocket-powered chainsaw to me.
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.
> All I want is ...
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.
Wait, helix will get scheme before gnu emacs, aww
Authors are free to do as they please, but as an entitled member of the peanut gallery…aren’t there already enough small configuration languages? Seems like a distraction when there are already hundreds of schemes, Lua, Janet, etc.
In that case, Kakoune[1] (Helix’s main inspiration) is probably more your jam. You get an RPC interface and are free to script it from anything you want (shell to Rust is about the range I’ve encountered). It does mean that you don’t get the batteries you get with Helix (e.g. LSP support) and need to bring your own (e.g. kakoune-lsp[2]).
[1] https://kakoune.org/
[2] https://github.com/kakoune-lsp/kakoune-lsp
Is including batteries the main reason helix seems to have started taking off, while kakoune hasn't?
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.
I don't know if this is still the case but they were leaning towards Steel.
Relevant Github comment: https://github.com/helix-editor/helix/issues/10389
Steel: https://github.com/mattwparas/steel
It has multi cursor support. `Shift+C` to expand down one line or you can split the cursor based on select. Collapse all of them with `,`
Love helix. Lots of features are still needed, but it’s an excellent editor
I’m excited to try this remotely with DAP