Is Helix code editor better than NeoVim?
How is Helix different from Vim?
Quote from the official site:
By starting from scratch, we were able to learn from our experience with Vim and make some drastic changes. The result is a much smaller codebase and a modern set of defaults. It's easier to get started if you've never used a modal editor before, and there's a lot less fiddling around with configuration files.
He also took a lot from Kakoune, which will not be discussed here, but you can see Here.
Helix is written in Rust, no Electron, no VimScript, no JavaScript. It works noticeably faster than Vim, but the comparison is incorrect, Vim is full of plugins, and there are many more of them than in the Helix database.
Yes, Helix does not come as a bare blank sheet of paper, ready for further finishing with a file. It's already charged and ready to go. The faces of customization orthodoxies must now express deep disappointment. I, too, when I heard this, was not inspired, but tensed. But look at this list! What's extra here if it's a code editor?
Color scheme
All themes for NeoVim from the first page by popularity are available out of the box. We write “:theme” and click “tab” in search of what pleases the eye, or enter the first letters of our favorite theme. You don’t need to download anything, you don’t need to write anything in the config. Just. Comfortable. The same functionality is provided, for example, by the NvChad assembly for Vima.
Multiple Cursor
This is generally beyond good and evil. Press “Shift-c” and a second cursor appears, then “Shift-c” again and another one. Make at least 100500 cursors, press “,” to return to one cursor. At the beginning, the cursors are located one below the other, and allow you to do approximately the same thing that you can do in NeoVim in a block selection “Ctrl-v”. And much more, these are still separate cursors, and not a selection block. A couple of sentences cannot describe what they allow you to do. Just look at the tutorial, it’s like “:tutor” in Vim. Probably not everyone is as surprised as I am; later it turned out that there is a plugin for Vim that implements a similar function.
Fuzzy find
Like telescope for Vim, but it feels faster.
Tree-sitter
Creates error-tolerant and robust syntax trees for better syntax highlighting, indentation, and code navigation.
LSP
When I started writing the config for NeoVim, I didn’t even know what the Language Server Protocol was, examples from the Internet didn’t work, it took me several days to get nvim-cmp to work.
Everything is screwed to Helix itself; you need to type “~helix –health” in the terminal to see the list of available LSP, DAP, Formatter, Highlight, Textobject, Indent. Then install the required package, for example, in Arch Linux for C/C++, run “~yay -S clangd”, or “~yay -S pylsp” for Python. Voila, autocompletion works. And the function arguments are highlighted when entered, and the documentation is updated.
Surround
Similar to nvim-surround plus auto-close brackets.
Git integration
Changed/deleted/added lines are highlighted by default. Maybe something else, I don’t know.
I am one of those who spent several months combing and adding to my Vim config. It was an interesting time, a useful experience. The result was an excellent tool, convenient for my tasks, flexible, powerful, fast, lightweight. A pleasure to work with.
In the second half of working on the config, when I had already configured the main things and everything was almost perfect, while reading another article about NeoVim, I saw that the topics overlap, roughly, by 50-80%. Same plugins, same recipes.
That is, the best user experience has already been formed, and the majority solves the same problems in one way. Helix has collected the best experience and made it the default. It just saves time.
But there are other, more significant differences.
Editing model “selection -> action”
In Vim, we first select an action, then its scope:
“di(” – delete everything in brackets. In Helix, first select, then select the action: “mi(d” – match inside ( delete. In my opinion, this model is more intuitive and natural. It’s more comfortable to see What you change before you change. After Vim, this, of course, is annoying, not pleasing, but this is just a matter of habit, several days or weeks of use. Both models are viable in principle and have existed for a long time. In the end, in practice this only leads to the fact that instead of “dw”, you will press “wd”
Simple config – toml
After Vim, we are not afraid of any config. But some configs pleasantly surprise you with their simplicity and clarity. And then there’s also brevity. I think the working Helix config will be somewhere 10-50 times smaller than your Vim config. And it was very nice to see the simple commands “:config-open”, “config-reload”.
Example config:
theme = "kanagawa"
[editor]
line-number = "relative"
color-modes = true
[editor.cursor-shape]
insert = "bar"
normal = "block"
select = "underline"
[editor.statusline]
mode.normal = "NORMAL"
mode.insert = "INSERT"
mode.select = "SELECT"Pop-up help windows for hotkeys
In compound commands, such as “gg”, after pressing the first key, a window with hotkeys appears. There is a lot in common with Vim, it feels like about 70%. And in my opinion the changes are for the better. Vim had “d” and “x” which do about the same thing. Helix only has “d”. It's more orthogonal. These pop-up windows can probably be disabled, I haven’t dug yet, they help in the beginning.
What about plugins?
But they are not there yet. But they definitely will. Possibly in Scheme language. There is active discussion in the community.
A few words for emigrants from the world of Vim
Get ready, there will be pain, the biggest pain will be when “x” selects a line and does not delete what is selected or the character under the cursor. And also dd and yy will only work on the character under the cursor… But these are all trifles.
Philosophy and prophecies
Some may wrinkle their nose, saying that this is not the Unix way, one program should solve one problem, harvesters and boxes are not work.
In my opinion, there is one fundamental difference here. When they made IDEs and other large-scale packaged products (such as Photoshop, Autocad), people thought about what the user needed in their work, how best to do it, and implemented it. There were some good and some not so good decisions. Then time passed, new functions were needed, it was necessary to maintain backward compatibility, so the combines became increasingly heavier. On the one hand, they became better, they knew more, and on the other hand they accumulated a bad legacy.
With Helix something is different. First there was the minimalistic but flexible Vim editor. Which over the years has been made even more flexible. And the community has written a trillion plugins, ranging from file navigation to “brewing_coffee” and “bringing_slippers_to_the_bed.” These plugins have undergone natural selection. And only now that we already know what all of us who write code in the modal editor need, and how best to do it, have now it been integrated. And a lot has been revised in Kakoune, now Helix is trying to bring the best of both. And he succeeds. Look at this discussion of hotkeys.
Metaphorically, this is not building a combine harvester. This is exactly how evolution works. First, individual forms appear, they are tested, the best survive, then they are integrated into larger systems. And so many times.
So, to sit down and immediately write a project for a person with all his eyes, ears, nervous system, organs, colonies of “digestive” bacteria in the intestines and with much lower-level subsystems – apparently even the architect of this world was difficult. And he wrote this project in parts, refactoring from time to time, and discarding entire modules (like dinosaurs).
With this approach, successful solutions can be identified over the years, and the bad legacy itself goes to the bottom of forgotten repositories. That is, improvements improve, and the bad dies away without disturbing anyone, due to the fact that these are all separate pieces, and not an initially integral system.
It seems that “this has never happened before, and now again” changes have come.
system V -> systemd
xorg -> wayland
neovim -> helix
Although these are completely unequal analogies between long, hot and green, I see the same principle in these changes – the integration of proven elements. And creating a new project from scratch based on lessons and experience with its predecessor.
The end of the NeoVim world is definitely not near. But Helix is a very likely replacement. It's a pity that the name is not PostNeoVim / pnvim. And he cannot possibly call himself a purebred descendant of ancient magicians vi.
Some numbers
Number of stars on Github:
Vim – 35k
NeoVim – 79k
Helix – 30k
Number of lines of code:
Vim – 1.8m
NeoVim – 1.5m
Helix – 0.5m
Post scriptum
I haven't switched to Helix, but I think I will. The project is only 2 years old. It still lacks some of the features I need. No folding. There is no tree view of project files (in my dev projects you can do without it, but when working with a blog where there are many more files and different formats, and many identical names, but located in different folders, fzf is not convenient here).
And if with navigation you can still solve the issue with crutches, hacks and separate TUI file managers. It seems that folding is not yet possible. Well, of course, there is no support for working with the Russian layout in normal-mode either.
I will watch the development of the project with interest. From time to time I try to type simple texts in it, waiting for the plugin system. There is something I like about it, in its very essence, philosophy. Helix usually charms Vim users, rather than disappoints them. And in my opinion, the future belongs to him. And some are already working on their projects in Helix.
What do you think? Have you tried it yet?
Links:
– Project website
– Github
– Hotkey documentation
– Discussion of hotkeys
– Discussion of the plugin system
– Migrating from Vim
– Hack with yazi file manager
– About the mentioned editor Kakoune
