Smart tab is so… smart. I really admire how people keep coming up with creative features that immediately make sense and become table stakes right away. This applies to editors across the board. Couldn’t imagine living without command palette in VSCode, for example. Smart tab looks like something I’d be using constantly.
Does anyone have experience switching from VSCode to Helix? I’m using a ton of different features of VSCode and for that reason keep thinking switching off it is hard. Debugging, keyboard shortcuts, command palette, multi cursor, all sorts of different languages, all sorts of different extensions (GitHub actions completions and checks, line wrapping that’s Markdown-aware, …), … it just does it all! The core downside is the reason I’m looking to switch: performance.
> I really admire how people keep coming up with creative features that immediately make sense and become table stakes right away. (…) Couldn’t imagine living without command palette in VSCode, for example.
Command Palette isn’t a VSCode invention. Sublime Text already had it.
Helix also has multi cursor, but probably not as intuitive when you are coming from vscode.
Helix supports many languages without configuration, except installing the language server.
GitHub actions completions should probably work through this json schema with a language server, at least I didn't configure anything and when I edit docker compose files, I have autocompletion and validation.
https://github.com/SchemaStore/schemastore/blob/master/src/s...
Command palette - i don't know what you are using it for, but nearly every modal editor like (neo)vi(m) has a "command line" when pressing ':' where you can run helix commands https://docs.helix-editor.com/commands.html
With helix you can get most of the vscode features, except debugging, extensions and file management, though most of the extensions can be replaced with some other tools (depends heavily on what the extension does, can't be generalized). A plugin system is currently on the roadmap and is being worked on, but I don't think anyone could tell you when it's going to be ready.
> Command palette - i don't know what you are using it for
Discovery!
No doubt, command mode in vim et al. is probably the most powerful thing. However, as with anything shell, it all has to be laid out a priori.
Command palettes are fuzzy-finding, allowing reckless abandon for hacking into them. Single-letter commands have to be remembered, productivity suffers. Fuzzy is pretty much just as fast and grows with the user dynamically. I'll look into whether Helix has that.
Ah okay, then you want Space-? It fuzzy finds alle the available commands and shows you the keybindings next to it, so you can even search for keybindings.
I've been using Helix full time, professionally as a Rust/Golang engineer and it has been great. It took some getting used to not having a file explorer. But now I think I am better for it.
These looks to be fantastic updates, I especially dig the diagnostics (if that is part of the release as well).
I also use Helix full time, I really like it, especially the multi cursor features. I was a neovim user before, but I did not enjoy configuring my editor all the time. I like Helix config defaults, LSP works out of the box, the commands are a bit longer to type, but more logical. I cannot work without a file tree, I settled with the tree explorer fork[1] and I'm happy with it.
Yeah I've considered it. For now ranger in a pop up term works nice enough for me. Ranger is a bit slow so I should move to lf or some other alternative.
I mainly use ranger, or some conveniece scripts I've built around ripgrep, ripgrep replace and fd. When i find the file i want I either open it directly to do a small chance or use the fuzzy search in my long running session to open the file.
The only thing I haven't nailed yet is creating files in deeply nested directories.
In general most of the things I used in nvim have now moved back to the terminal which has its pros and cons.
I just started using a modal editor this summer. Started with vim, progressed to neovim and landed on helix. I love the batteries included features and minimal configuration. Using a scripting language (Lua) for configuration was bit too much overhead for me to get started with neovim. I felt immediately productive using helix. I also prefer the selection->action model as well as native multi-cursor support. I would definitely recommend it to anyone looking to start using a modal editor. Experienced vim users might find it irritating to adjust to helix. In my opinion, it has the best out-of-the-box experience of anything I have tried so far. Though I will admit that Intellij is paying the bills for now and I use helix for all my school work. I hope to get helix to be my daily driver eventually.
As an avid neovim user, I must say helix felt right at home. There are differences, but most of the basics are the same. I felt immediately productive. Great job. (Neo)vim compatibility, makes this much more approachable for those familiar with vim-style modal editing.
I like Helix, but I get annoyed by a really tiny thing. When you hold the left and right arrow keys, the cursor will go to the prev or next line once it reaches the beginning or end of the current one.
Which is completely fine behavior, to be clear. I just can’t deal with it. vim does not do this.
Which is 100% intended, as also in (neo)vim commands like f, t, etc only operate on the current line, while in helix they actually work and take you to that character, no matter if it’s in the same line or 400 lines later
Fantastic updates. The multiple LSP was the main missing feature but now this makes Helix ready for all use cases imo. It is super fast and performance unlike the disastrous performance of vs code.
I used Helix for a while due to its support for LSP out-of-the-box, which my Vim config at the time couldn't live up to. I switched back to NeoVim after finding LunarVim[1] which had everything I was trying to get setup in my own config.
I’m a big fan of LunarVim, but handling large files out-of-the-box is not a great experience. Observed in both lvim, and neovim with my own config. I’ve found myself leaning on helix in those cases - quicker than screwing with either config, or running vim -u NONE.
LunarVim is my daily driver, but Helix is screaming fast compared to it in many cases.
I'm actually impressed at how nicely they answered the request by explaining why it's so large, pointing out a few workarounds, explaining why it's not currently a priority given their vision, and leaving the door open for potential future improvements. It would have been a lot simpler and less hassle to simply ignore it or close it with minimal discussion.
Genuine question: why does storage size on disk matter, especially when we're talking about ~100MB?
I can understand complaining about RAM usage because there is some performance impact there, but I have truly no clue why anyone cares about storage usage.
Other than the initial download time, I don't see how it would have any impact on the end-user.
Of course, it would be _nice_ to get that package size down if it's easy, but to me it seems unnecessary to prioritize.
For my Arch system I have a 60GB (BTRFS, compressed) root partition, and I install packages very liberally, I have KDE Plasma, KiCAD (with the 3D library), FreeCAD (though I don't use it) and quite a few other packages and haven't run out of space yet (currently I'm using 79GB uncompressed, 55GB on-disk)
Helix uses tree-sitter for rich language support. Tree-sitter's grammars are binary dynamic libraries compiled from some source code. Depending on how they are written and how complex they are, they can be anywhere from few KB to many MB. There's like 150 of them ATM. It's not exactly Helix's fault that some are unreasonably large.
Tree-sitter is a large part of what makes Helix editing experience so good. Unlike regex-based parsing that (Neo)Vim uses (or at least it used to, last time I looked) which often break in weird ways and make the editor very sluggish sometimes.
Helix official releases ship with all the supported grammars pre-compiled to give a convenient fully-featured user experience. It's entirely possible to package Helix without grammars, then compile selected few and so on. Some distros and individual users do so. Grammars compiled by distros / package managers can be re-used between other programs using Tree-Sitter, so could be packages as additional (possibly optional) dependencies.
Honestly 140MB for such a good editor is totally fine with me, but people who can't live with it have plenty of routes to take, like improving Helix integration in their package manager of choice.
helix is the only editor that gets this right. shipping pre-compiled grammars should be the default for any editor leveraging tree-sitter, from a user experience perspective and for stability.
the fact that more popular editors expect you to check them out yourself and compile from master and then wire everything up yourself and "hopefully there's no incompatibility today!" is insane. we should really have higher standards than that.
More popular editors expect you to click a button when you open a file in a given language to install language support, nothing insane about that, easy and also no waste
It provides a rare but obvious criticism which these people are sorely lacking. You can tell this is true by how many of them replied to it telling me that the placebo effect made them feel a lot better about this new editor. And of course it's on to the next thing once the honeymoon period wears off and some new shiny set of keys is dangled in front of them.
I mean, I don't know why I'm replying to you, but Helix absolutely does try new things that no other editor does the same way, and it's obviously intended as a successor in spirit to vim..
maybe you don't see value in someone trying to improve the modal editing idea that came around forty-odd years ago with vim but someone certainly does
Whatever these things are, they can't be very impressive if they weren't worth putting on the front page. Can you tell me one of the new things? Because I can't find any.
Since you asked, I've been using it recently and it feels like a more responsive version of Neovim/Kakoune. It's a very good editor, I upvoted this article in the hopes that someone else would try it too.
