I really like the Helix editor
62 points by mond
62 points by mond
I really like it as well, and most of the pro’s and nitpicks resonate with me as well.
It has nice defaults and it’s fast. Through kakoune and helix I found out that one of my favorite ways to “script” is to delegate certain things to external tools and select->act modal editors make for a great workflow. It’s a form of a composability that I think is underrated in editor tooling. I’ve gotten better with my editor, but also with things I can re-use outside of the editor.
I’ve also been using the fork that includes the plugin system: Steel for a few months now, and even that config is small and cosy. There is a lot less need to script things when you can easily glue things together with builtins.
Using lots of external tools does have downsides, the annoying one being that config parts are scattered across my ~/.config/ folder in a variety of formats(toml, yaml, json` usually) and theming colors are bit off if I switch editor theme. But it’s not a dealbreaker by any means.
Selections in multiple buffers(like in Zed multibuffers or Emacs occur-mode) is something I’m looking forward to as well, there has been some interest in it at least: https://github.com/helix-editor/helix/pull/4381#issuecomment-1382831419
Interesting point about the selection flow not yet working across buffers. It seems to be the case among editors that turning in-buffer flows into multi-buffer flows adds some complexity that is not trivial.
It’s definitely not easy! The way kakoune and Emacs solve it I believe, is collect all the search results in a (text) buffer with filenames/lines in it as well and then you can edit the buffer as any, and call a function to save the edited lines to their respective lines.
Zed’s multibuffers are another level wrt UI/UX.
I also recently switched to the Steel branch but I haven’t had the time to write anything interesting with it yet. My dream plugin would be an integration with ast-grep with a search picker and interactive replace but I’d have to understand how the component system works before that.
Do you have any good snippets/cogs to share?
Yea I haven’t fully figured things out yet (on the Scheme side and the way Helix works), but here are some links that might be helpful:
You might be able to write Steel bindings for the ast-grep Rust library (if it has one), call it from a function in helix with params, and display the results, potentially in a picker?
edit: you might be able to use the CLI of ast-grep.
The scooter plugin looks very interesting, thanks! I’ve had a look around mattwparas’ config, I just haven’t sat down with it enough to understand how everything works.
I can imagine that it takes a whole to comb through the entire config because it’s the resulting work of several iterations of the plugin system.
More specific questions could always be asked in the Discord of Steel or Helix’s matrix channel!
Indeed, pat the editor :)
I’d say out-of-the-box usability and the interactivity of the select-then-act paradigm (also present in Kakoune) are probably the tops of Helix’s strengths. Two issues that caught my eye - Zed-like multi buffer multi cursor actions and moving the viewport without moving the primary cursor - are things we definitely want. Multi buffer needs some new UI work, definitely a larger effort. Allowing the viewport to move independently of the primary cursor will take some refactoring as things assume that the primary cursor is always in view.
After the next release I’d like to focus for a bit on furthering out-of-the-box usability: adding imprecise tree-sitter versions of LSP features like symbol pickers and goto-definition/references. GitHub uses tree-sitter like this.
And working in the Steel PR gradually. The only part of this that worries me is exposing APIs to plugins which are based on parts of the core that need rewrites/improvement, like config. Probably we will integrate Steel as very experimental at first so we don’t commit to bad interfaces out of the gate.
Nice writeup.
One thing I would like to point out is that the main flow shown here (making selections matching some text, expanding each selection to the containing JSON object, doing something on each selected object) can also be achieved with “jq” (as the article says) but also with regular vim macros.
Sure, the article makes the case that things like Vim’s select/replace and macros are too low level, slower, or for the ’utterly deranged”, which might very well be the case. I just wanted to point out that a vim user is not limited to an external tool (jq) to solve this particular problem.
I much prefer multi-select to macros (which Helix also supports) because you see what’s happening in real time and can undo just the last step. So it’s way easier to make incremental progress and not get stuck in a slow iteration loop.
Kind of like using a REPL compared to writing a function in your editor.
Helix had been my daily driver for two years at this point.
Having built in support, including lsp and tree sitter integration, for so many languages means i never need to spend time in config.
My config is two lines: relative line numbers and theme.
I moved from Emacs to Helix because LSP configuration in Emacs felt hellish and it was always so slow - Helix just werks™.
Haven’t heard about Helix before, but it sounds interesting! Not long ago I set up Neovim with an LSP for Elixir, and it was a struggle to figure out how to install & configure lazy.nvim and various other plugins to make the LSP work. Helix sounds better in that regard, assuming it supports Elixir.
I use Elixir and Helix, it’s 0 config if you use elixir-ls, and probably 2 lines of config if you use another one.
I have the following for Elixir in my languages.toml:
[[language]]
name = "elixir"
scope = "source.elixir"
language-servers = ["lexical", "hx-lsp", "tailwindcss-language-server"]
[[language]]
name = "heex"
language-servers = ["lexical", "emmet-lsp", "hx-lsp", "tailwindcss-language-server"]
But this also includes snippets/tailwind/emmet completions, these are optional.
I’d say some other editors have certain Elixir niceties you can’t get out of the box, e.g. running a test from where your cursor is, or a nice iex integration.
Not having used Elixir yet, I am 99% confident Helix supports it. The ecosystem is standardized around LSPs and treesitter, both of which almost certainly exist for Elixir.
I’ve used Elixir with Helix, you don’t need any configuration other than having elixir-ls in your $PATH and maybe setting [language-server] elixir-ls = { config = { elixirLS.dialyzerEnabled = true } } in your languages.toml if you want to see errors from Dialyzer.
I like the idea of Helix and having more sensible defaults baked in, but every time I try to use it I end up configuring it as much as I possibly can until I hit something that I am unable to configure the way I want.
Has anyone used Helix with QMK (firmware for mechanical keyboards) and managed to configure it to actually be able to parse its C files? I’ve got clangd configured and working, but it doesn’t understand that the project is a cross-compilation setup and hits errors that mess the whole editor experience up. :(
I also like Helix editor. I used to use neovim for long while, but I found myself tinkering with configs more than actually working on things.. Not because it was broken, but because I got addicted to the whole “just one more plugin” thing.
Helix is just perfect out of the box for me, but I have my own very small config and some shortcut changes.
My personal choice is still Kate editor because it’s easier for me to use and straightforward, but I always end up using Helix when I’m in terminal.
I went the opposite way: 12 plugins with neovim is all I need.
https://erock-git-dotfiles.pgs.sh/tree/main/item/dot_config/nvim/lua/plugins.lua.html
My preferred way of doing search-and-replace ops is with Zed, because it combines multicursor movement across multiple buffers in the same view. No other editor provides this type of interface, so even though I use vim as my main I switch to Zed every time for bigger refactoring tasks.
I use grug-far in (neo)vim and it works great for me, haven’t tried Zed though so can’t compare.
No other editor provides this type of interface,
VS Code has something similar with search editor, though, sadly, it needs a plugin for writing the changes out: https://marketplace.visualstudio.com/items?itemName=jakearl.search-editor-apply-changes.
And I would guess that Emacs was the editor to popularize “edit across files” paradigm? https://www.masteringemacs.org/article/searching-buffers-occur-mode.
I’ve been using Helix daily for several months now. The LSP and treesitter integrations are great. I also am a fan of the picker(s) interface. For my usage, Helix balances being functional, opinionated, and hassle-free. It also has a friendly Matrix community.
There are only a couple of vim features that I regularly miss (or haven’t found helix equivalents for yet), in case a helix fan here has suggestions :-). A yank-ring / kill-ring equivalent. And a vim repeat “.” equivalent. (Repeat in helix doesn’t repeat the motion, only the action.)
Helix is fun to learn. I hope it continues to find fans and grow!
Do you frequently use machines on which you do not have blanket install rights? Tough luck, as far as Linux servers go, Vim is basically everywhere. Helix isn’t. If you can’t install Helix where you work, it’s probably not the editor you should invest time into!
This one isn’t too bad if rustup/rust is installed on the machine or you can get a precompiled binary on it.
I daily drive helix since 2 years now and honestly am very happy with it. I like the modal model a lot more then the one of vim (which i was using before). LSP support built in, amazing! Only thing i miss is keyword completion. Not super needed if the lsp support is good, but still need it every now and then.
Are you married to your existing Vim keybinds? Does the thought of having to relearn a few old coding habits pain you? Helix gets rid of keybinds such as dd or D. dd in favor of xd, where x selects the whole line, while d deletes whatever you have selected right now. This follows the ‘selection first’ principle. First you select something, then you apply some action. There’s a lot of more obscure ones that don’t work either.
This is quite interesting. If Helix’s keybindings make a lot of sense, I hope someone can give me an evil-helix-mode for Emacs.
If Helix’s plugin/scripting system can be as nice to use as Emacs’…. might be time for moe to jump ship.
There is one in development: https://github.com/mgmarlow/helix-mode
If Helix’s plugin/scripting system can be as nice to use as Emacs’…. might be time for moe to jump ship.
Emacs is a different type of editor, Emacs really does treat everything as text, whereas Helix has opinions. If Emacs works for you right now, I wouldn’t say you have a lot of reasons to jump ship, but do try it out!