The Helix Text Editor (2024)
jonathan-frere.com107 points by gidellav 5 days ago
107 points by gidellav 5 days ago
Hey, that's me! I wrote this about a year ago, and I'm still using Helix, and still quite happy with it. The lack of a plugin ecosystem is sometimes irritating, but work there is slowly progressing. And I'm still not a fan of the idea of building the perfect IDE by composing different TUIs together and spending hours trying to get a perfect setup. But other than that, editing in Helix feels so fluent and fast that I'd really struggle not to use it if I went back.
Hi! I started using Helix about 1 month ago, jumped from Emacs, and I have to say that I really prefer this minimalist approach where I have just two tabs on my term emulator, one for Helix one for git/compiler/etc, and I honestly don't feel the absence of plugins, except for maybe a better find/replace symbols like in VSCode could be nice.
Well, thanks for your article!
I'd love to switch to helix from emacs - I really like the editing model when I have tried it. However I write a lot of clojure and the lack of a REPL in helix and reliance on using LSP for everything (which just isn't as good as repl integration) is a bit of a blocker. I hope their plugin system and embracing scheme for it means that some kind of REPL capability will be implemented and supported well. I hope that plugin branch is merged soon.
You might want to have a look at Matt Paras’s config. He’s been developping the plugin system using steel, his own scheme interpreter in rust. To send things to the repl, it uses eval-buffer from the helix-ext.scm file.
The integration and customizability is for sure not that of Emacs yet, but with the plugin system soon to be merged, we can hope to have a proper REPL and Parinfer implementation!
Regarding open files, <space>+b opens up a picker for the files in the buffer.
There is also now a file explorer under <space>+e (little e for starting at workspace root, capital E for starting in the buffer’s directory).
I've not actually used the file explorer much, but I've seen that it's there. I assume it can't do file moves or deletes, though? That's the one thing I really miss from file pickers in other tools, otherwise I find the fuzzy search approach really convenient.
I should definitely use the buffer picker more, at the moment I use the gn/gb commands and it mostly works, but then I suddenly end up with too many open buffers and it's hard to figure out where I need to go again.
Yeah the file picker can’t do moves or deletes. Personally that’s a rare enough part of my workflow that I don’t mind doing it via the terminal.
Wait what?!
There's a file explorer now!
Just tried it now, it's not quite a file tree but it's almost as good.
I have been checking in with helix every 6 months to see if the plugin system was finalised so I could use a real file picker and actually navigate through and explore the files in my project.
That one thing has held me back from using helix. I'll probably give it another go for tiny projects where I don't need any plugins (e.g. in-line error annotations through LSPs, indent rainbow, in-editor color pickers, line sorters, etc...).
> And I'm still not a fan of the idea of building the perfect IDE by composing different TUIs together and spending hours trying to get a perfect setup.
OTOH one could build distrib similar to spacemacs/lazyvim, then you could just start with that, and once you find one particular plugin annoying or lacking, you could swap it for something else, at least theoretically (I've never used those personally, so I don't know how hard it is in practive). Not so much with all the eclipses and jetbranses of the world.
Is Helix good for Markdown-based note taking workflows? I suppose no, because plugin system is yet unavailable.
You could try your luck with Iwe, it's an lsp server for notes and markdown: https://github.com/iwe-org/iwe/
How strange that the article never links directly to the Helix editor. I usually immediately open the homepage of whatever a blog post is talking about as a background tab to be able to click back and forth, or to be able to immediately figure out what the thing being talked about is, but no luck here, except for some decoys (like the "helix" link next to the title which is just the tag "helix" which sends you to a page with all the posts tagged with "helix", which happens to just be this one post).
I of course quickly just googled it myself and found the page, and so afterward I went to the source of the blog post and searched for the URL to confirm that it wasn't actually linked to anywhere. Turns out that about three quarters of the way down, in the "Key Bindings" section, there is a link to the Helix keymappings documentation page, which appears to be the closest thing to a direct homepage link.
Anyways, no nefarious intent being implied of course, I just found it sort of interesting. I am pretty certain it just got accidentally left out, or maybe the project didn't have a homepage back in December of 2024 when this was originally written? Although the github page isn't directly linked either (only one specific issue in the github tracker).
Oh, and here's a link to their page: https://helix-editor.com/
And github page: https://github.com/helix-editor/
Yes, it was pure accident! I surely had the helix homepage and documentation most of the time while writing this, but only thought to link that one bit of documentation! When I get to a computer next I'll update it with a link, because that would be useful.
Not linking to stuff is the new normal. Many subreddits ban you if you post a link to source. Tweets no longer contain links - you need to click on tweet to see the next ones that maybe contain the link
> Not linking to stuff is the new normal.
Maybe in certain anti-intellectual crowds. But not here.
Reddit behavior shouldn't restrict you elsewhere.
What? Can you give some examples? I don't use reddit anymore but this sounds unbelievable to me. They ban you for providing a source?
Long-time (Neo)Vim user, tried Helix for a few months but just couldn’t get on with it.
It felt too inflexible (not just from lack of plugins), and there were numerous annoyances like save always changing file ownership to the current user, the buffer not reloading when a file is changed externally, no way to highlight (only) trailing spaces, dot repeat doesn’t always work (because the motion/selection comes first) etc.
But mostly I much prefer the way Vim does selection and motions and actions etc.
I wish I could pipe stuff to helix without having to deal with not saving the buffer.
I also don’t like bulk search and replace in helix as it’s based on selection and replace.
Other than that, I find it easier to stick to helix than to vim!
I wanted to provide an anecdote because I hold the opposite opinions of the author in a variety of ways, but still have used Helix as my primary editor for years now.
I don't chase shiny new tools nor do I aspire to replace my toolchain with things just because they're built in Rust. I've used vim/neovim ~15 years. I don't use many TUIs (I actually can't think of any others besides my editor), but my development workflow is entirely terminal-based. I use native splits/tabs in my terminal emulator instead of screen/tmux/zellij. I spent years balancing having a minimal vim configuration that included plugins (but not compiled ones so that it was portable) but didn't include hundreds or thousands of lines in my vimrc. I'm excited to see how neovim is making progress with native LSP, but for years getting it working meant continuously tweaking vimscript/lua code or adopting a massive plugin written in TypeScript.
When I first tried Helix, LSP just worked; it read what was on the $PATH and used it. That's perfect because it solves for another source of annoyance: having different versions of tools for different projects. As the author notes, there are some LSP features that don't work with Helix, but whenever I dig into the issues, I almost always come to the conclusion that the issue lies in LSP being a VSCode monoculture rather than a deficiency in Helix itself. However, using the right version of a tool for a specific project and not spending any time configuring LSP servers were the top problems plaguing my usage of neovim.
If you're a vim user and you're concerned about muscle memory, by the first week I was proficient and by two weeks, Helix was the default in my brain.
I was a huge supporter of neovim -- I actually was submitting patches to the vim mailing list to fix vim on a beta version of macOS at the time taruda posted his original async patches that kicked everything off. If you had asked me the day before I tried Helix that you could reimplement a vim-like codebase from scratch well enough to abandon the original vim code, I would've agreed with you.
> I'm excited to see how neovim is making progress with native LSP, but for years getting it working meant continuously tweaking vimscript/lua code or adopting a plugin written in TypeScript.
Lua and native LSP supports were introduced at the same time. Not getting how you would tweak Lua code to get LSPs to work before Neovim had native support.
> LSP just worked; it read what was on the $PATH and used it.
This is how Neovim loads LSPs as well. You don't need a plugin to download and manage LSPs. You can just install them externally yourself.
> not spending any time configuring LSP servers were the top problems plaguing my usage of neovim.
It's been years since it's just a few lines to enable LSPs with the config shipped in nvim-lspconfig if you don't want to override any server-specific settings. And even then its still pretty easy.
I will give you that Neovim should ship with nvim-lspconfig and just load a compatible LS if its already in the PATH. Enabling each server one wants to use is annoying. But again, it's just a few lines (and I'm pretty sure a lot of people wage war if they did either of those things because "bloat").
I don't think my config works anymore (to my earlier point), but this is the balance I struck when I used neovim: https://github.com/jzelinskie/dotfiles/blob/426768c61078a77c...
I'd explicitly configure which servers were triggered which filetypes (aka autocmd and when I first started doing this, the binding for autocmd didn't even exist in lua yet) and have to bind lsp functions to keybindings across languages. FWIW, I have no idea what I would've done in vimscript, lua is a godsend with tables, loops, and lambdas. At this point in time, I was an early adopter neovim's built-in LSP and everyone else was recommending coc.nvim.
But the juxtaposition at the time was that Helix ships `languages.toml` that includes all of this already out of the box. You can override it, if you want, but actually all I wanted was cohesive keybindings for basic LSP functions.
What's the state of the world for neovim today?
> LSP just worked
Hi, just browsing. Where are you usually having issues with LSP these days? Is it a vim issue specifically, or related to your setup?
I believe LSP works across a multitude of editors by now.
What helix gives you is opinionated LSP support. With vim you first have to add some configuration and choose key bindings. I have used LSPs with vim before, but I wasn't sure which configuration makes the most sense. In addition, helix is optimized for discoverability: You get context menus for basic editing commands and LSP commands. This really helps with learning how to take advantage of the editor and the LSP features.
I use netrw to create files, and sometimes to browse. What do you use when using helix?
I was never a big user of netrw or nerdtree, but Helix has <space>+f for a fuzzy-finding file browser or more recently they added <space>+e or <space>+E for a hierarchical directory explorer.
I build HEAD from source using brew, so I'm not actually sure if the directory explorer is in a stable release.
How do you create a new file deep in a nested folder? In Helix, I think I used touch from a new terminal, but that’s a pain with deep folder hierarchies when I’m already in the correct slot in my editor.
The % register contains the path for the current buffer, you can insert that into prompt commands with <C-r>%. <C-w> at the command prompt deletes the last word, which in this case will be the filename of the current buffer, leaving the directory path.
So:
:o <C-r>%<C-w>new-filename<ret>
Would open a new buffer at /path/to/the/previous/buffer/new-filename. The file isn’t created on disk until you explicitly write, so :w! to save the first time.
If you literally just wanted to create a new file instead of opening a buffer, you could do that from inside Helix with :run-shell-command (aliases sh or !) instead of another terminal:
:sh touch <C-r>%<C-w>new-filename<ret>
The :o method has the advantage of LSP integration. For example, when I create a new .clj file that way in a Clojure project, the new buffer is pre-populated with the appropriate (ns) form, preselected for easy deletion if I didn’t want it.
Switched to Helix about a year ago and haven't looked back since. Has almost everything I need in it(with a few exceptions). With Vim I would've had to have installed some janky plugins.
I really recommend it if you find Vim motions unintuitive and want some of the basic features of IDEs like VSCode.
My biggest gripes: - No plugin system (yet). - Configuration documentation is not the best. - Hasn't reached enough popularity to where other apps have "Helix mode" like how a bunch of apps have "vim mode". I find myself wanting to do Helix motions in other apps.
I like Helix. I couldn't get Neovim to stick after a few tries but Helix let me into the modal editor world. Just works, no config required and their editing model is better for newcomers because you can see what you're about to do. I eventually switched to Neovim after a few months though (thanks to Kickstart.nvim), because configuring with a programming language is just so much more powerful.
That said, I'm convinced people praising Helix because they "don't have to install 60 plugins" or "constantly keep tweaking their config" will just start blaming Helix when it gets plugin support and if it gets a dynamic configuration language.
You don't have to install 60 plugins (I have 6) and you don't have to keep tweaking your config (I haven't touched core parts of my config in years, just like to play around with logic sometimes). It's not a feature to not support these things just because you lack the self control to stop playing with your editor and focus on your work.
I tried to use helix as a vim user, but couldn't get used to the key binds. However I recently found evil-helix, and it's a joy. https://github.com/usagi-flow/evil-helix
+1 for evil helix, however the default keys are not 100% compatible with vim needing some more tweaking with the settings.
For example C is not change line as expected but multi line edit mode (something not very useful with vim keybind) ...
But even with these quirks it's close enough to be usable and enjoy all the goodies of helix.
From the README:
> Scheme/Lisp should not be forced onto the user. It's error-prone and harder to read by humans, compared to Rust/TOML/Lua/...
I get the argument of preferring TOML over a Turing-complete language for configuration, but to claim that Rust is easier to read than Scheme, or that Lua is less error-prone, is... interesting, to say the least.
I saw similar comments in the linked issue that tracks the proposal. I think people object more to functional programming and S-expressions than to Scheme itself, which is a shame. There's a lot to be gained and learned from Lisps once you get over that initial reaction.
> This has some advantages — for example it means that Helix is very responsive and lightweight, because there’s not a lot of heavy rendering work to be doing.
Which text editor is unresponsive because of heavy rendering?? And that's the only potential benefit the author has identified
I remember pasting a lot of text in vim. And waiting for all of it to be rendered. In helix it's instant. Things could have changed since then. I am talking about no later than 2023
(Neo)vim is usually very fast.
In Neovim at least one reason for why it might be slow is that the particular treesitter implementation for the syntax you're using isn't very optimized?
But it depends a lot on what kind of type you're pasting exactly and your setup.
Too bad the development of helix is pretty slow and core devs are pretty resistant to various of changes.
It would be benefit a lot from some funding, but it's hard to find funding for a TUI editor.
It insane how fast Zed is moving in terms of development, on the other hand, I'm still waiting for some features in helix for more than 2 years. Helix devs have their own vision and reject a lot of attempts/PRs to make it better.
Regarding slow development, I saw a thread on reddit today https://old.reddit.com/r/HelixEditor/s/zn0xiSs9pp
What important features are missing?
While I’m looking forward to the plugin system for a few nice to have tweaks, and amrunning the dev branch alongside the main build to check it out, there’s nothing really essential missing to me.
I appreciate that the maintainers aren’t trying to compete with vim or emacs for features or be all things to all people, aren’t that they don’t prioritise growing the number of users over keeping true to their vision for the editor.
Helix is all the better for its slow, considered development as far as I’m concerned.
- auto file refresh
- global replace
- multiline search in files
- small terminal with toggle (for quick commands)
- Recent LSP protocol features that would allow using inline copilot suggestions
- better file manager where I can create, remove, rename files
- an ability to bind x and xx (double) keypress at the same time
- git blame
- a better ability to run programs on top of helix (lazygit, for example, the same way people use it in neovim without closing it)
Many of these features are more IDE than editor to me and that perhaps explains our different points of view.
Personally I’d be quite sad if the core Helix editor ends up like a VS Code style IDE, or even like some of the more heavyweight vim/emacs configs I’ve seen. I prefer simple, lightweight tools with relatively narrow focus and for me there’s not a lot in that bucket missing from Helix.
I use panes in my terminal for e.g. quickly running commands and file management, and terminal tabs for e.g. quickly switching to gitui/lazygit or longer terminal and command sessions.
I prefer this because all the pane and tab management, file management tools, etc. are therefore the same whether I’m editing code or doing something else in the terminal.
Of course, once there are plugins, hopefully people who want those things from their editor can be catered for too.
Fixed link: https://old.reddit.com/r/HelixEditor/comments/1ne57ob/concer...
The original link only works for logged in reddit users
> Helix devs have their own vision and reject a lot of attempts/PRs to make it better.
I feel your pain, but i support their focus here. Not only does it help prevent feature soup but at the end of the day they're the ones that have to support all these things.
As always, anyone is free to fork it. That sounds short but imo true nonetheless. Especially if the feature is small enough that the fork is just maintaining a patch on the head.
Regardless, plugins are being worked on so in time hopefully it's less of an issue.
> It insane how fast Zed is moving in terms of development,
I imagine funding and bodies helps a lot on this front.
Helix is great! All of the features I wish vim had out of the box, and fast.
It would be cool if it got more token-based movement/selection/replacement features, since it already has good tree-sitter integration.
Was looking into Helix after recently starting to feel the urge to switch things up a little from vscode and not entirely enjoying trying to use neovim as almost an IDE. I remember enough keybinds to do basic editing, but not enough to smoothly flow between other modes/buffers without having to consult documentation. Didn't quite feel like Helix was what I was looking for either, in part due to the apparent lack of Copilot support(?) and lack of plugin support in general.
I'm finding that spacemacs seems a bit easier to use, striking a nice balance between vim style editing and emacs style everything else, making it easy to slowly build up memory instead of overwhelming me with keybinds and configuration details.
There are still things in (neo)vim that I miss, even a year or so later (particularly persistent undo files), but helix's startup time is so much faster (and LSP integration so good), I hardly use anything else.
A lot of the time I find myself highlighting things in NeoVim before I delete/copy them. Probably from years of interacting with text in GUI applications, it just feels more natural. I've heard about Helix's approach before and it seems like it would fit well for me, but I can never bring myself to switch. Probably a little sunk cost fallacy because of how much I put into learning NeoVim, and a little about being able to customize it. I don't do a lot, but I like what I've done, and more importantly I like that I have the options.
I am a long-time vim user and tried out helix. In many ways it's great but the fact that there was (at that time) no "reflow text" function made it just completely unusable for me for basic text-editing outside of code.
If that's been added I'd take another look.
Reflow in the sense of wrapping blocks of text? That exists, I think under :reflow, although I always forget the name when I'm looking for it.
this is the kind of thing kakoune (helix's primary inspiration) excels at --- i can hook `fmt` to a non-whitespace character insertion and have auto-reflow as i type. of course, this requires the user implementing the script to get it right, but then you can pr it into kakoune's "stdlib" which gets loaded by default, so any user can use it. (though helix is getting a plugin system eventually, which hopefully alleviates the pain of slow merges.)
I love the batteries-included nature of Helix. Especially for people with no prior experience with modal editors, it has a much nicer learning curve compared to vim.
Happy Helix Editor user here! My favourite text editor
I now just use micro and be done with everything else.
[flagged]