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.
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.
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.
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.
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.
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)
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 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.
> 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.
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
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.
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.
Readit News
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.
Deleted Comment
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?
Deleted Comment
https://zed.dev/
https://github.com/helix-editor/helix/issues/6187
> 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)
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.
Deleted Comment
* 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
Deleted Comment
How did you lose work, though, could you not redo?
Deleted Comment
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.