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.
It's basically the same thing. The difference is that in Helix (and Kakoune) you are always have a selection, even when moving with hjkl, and any actions operate on selections. In contrast with Vi works in a "verb-object" grammar by default, like dw to delete a word. In Helix that would be wd.
I also really like helix. It could be my way out of my horribly cursed usage of emacs-with-vim-bindings-but-also-using-some-of-the-emacs keys.
One major issue that makes me uncomfortable with it is that it blindly trusts anything you open in it. https://github.com/helix-editor/helix/issues/2697 describes the issue but I think it's not immediately clear from the issue description that if I can get someone to clone my project and open a file from it in helix, I can run whatever I want on their machine by defining a project-local language server:
then they open a python file in my project, and it adds their machine to my botnet.
There's certainly a significant amount of "yolo" I practically have to do in terms of running new code without reading it in daily life, but I don't really want to expand that to everything I open in my editor, so it's a dealbreaker for exclusive daily use. I also don't think most helix users are aware of how wide open it is.
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.
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.
I actually like the way that vim solves this problem with the quickfix list. The quickfix list is populated by your project-wide search (e.g. builtin :grep or similarplugins) and then you can just use normal vim commands for every entry in that list, e.g. the search-and-replace example would be a simple :cdo s/foo/bar or what I often do is record a macro and replay it across all lines with :cdo norm @q. You can also easily filter the quickfix list with the builtin :Cfilter and if you want to have the immediate live-preview across all files, there is even a plugin for editing the lines being pointed at directly in a buffer, although it's arguably not quite as polished as the UX from Zed.
The reason why I like the quickfix feature so much is that it is the same interface being reused for completely different mechanisms. For example it will also be populated by compiler error locations or by much more obscure external tools such as git-jump. Think about any problem that involves source code locations across the entire project, and the quickfix list will probably be the most idiomatic solution in vim.
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.
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.
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.
I've got a lot of love for macros (and also use them on Helix), but there's a few things that I always found hard with them to do.
One of the things that I find tricky is specifically excluding certain things. For example, in the multi-select workflow I can use a keybind to remove all selections that follow a certain pattern. My understanding is that (with a macro workflow) this is much harder, since it amounts to a conditional. The best you can do is performing a highly specific jump at the start of your command, so that you skip over those cases you don't want to edit. (But this always felt very tricky.)
I might be wrong though, I'm absolutely certain there are some dark magic-type macro tricks I just never learned.
I'm also not a macro wizard, so I can't confirm either. I guess the general macro answer would be to "try to specify the problem without a conditional, or write a function." If there are better ways to do this on Helix, that's a big thing.
For this that still like vim, but multi-selection, there's vis, which is the happy mix of vim+sam (plan9's editor), which brings structural regex (read multiline) for selections.
In the case of vis, the author's flow for renaming "foo" would either be to set selections to all strings matching "foo", then change selection to "bar" :
I used vis for a number of years before switching to Kakoune and eventually Helix. I'm glad to see it's still going! I think this was before Neovim got Lua, Tree-sitter, and LSP support so I'm not sure if I'd still make that switch today but at the time it served me well.
My helix config is similarly small. A third configuration item that I find useful is binding file_picker_in_current_buffer_directory, especially in projects with deeply nested directories.
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 haven't personally tried this yet, but did you use qmk generate-compilation-database to get a compile_commands.json and ensure that clangd picks that up?
Turns out this post was what it took for me to try this out. The tutor is neat, and coming from Vim, took surprisingly less time to get used to the basic editing flows. And now my vim setup feels ancient in comparison. I specifically like the way diagnostics are handled in helix with floating text at the top but "signs" in the sign column. Basic git markers/signs are nice and unobtrusive.
Editors like Vim, Emacs, Helix have an often-overlooked advantage - identical keybindings across OS platforms. In contrast, editors like VS Code and IntelliJ have different (platform-compatible) keybindings for the same function across Linux, Windows, macOS, etc.
What editors like VS Code do give you is:
better accessibility
a proper GUI interface. This is subjective, yes.
In my experience, use cases involving flat-level multi-cursor selection are fairly replicable in VS Code.
Take the first example in the post:
Press %. This selects the entire file.
Press s. This opens a ‘select’ input field in the command bar.
Type foo. This will narrow down your current selection to only select all matches of foo. In other words, you now have every match of foo in your file selected.
Type c. This replaces each selection with a cursor, and puts you into insert mode.
Type bar. You’re editing all instances at the same time.
In VS Code on Linux, I would do it as follows:
Press Ctrl-F. This opens the Find interface.
Type foo, then press Alt-Enter. Each instance of foo will be selected across the file, with a cursor put after each selection.
Type bar. You're editing all instances at the same time.
I think VS Code can even replicate Helix's S function to some extent - split selections further into sub-selections with a regex match.
But, inverting selection (Alt-K in helix) isn't possible in VS Code without some extension if it exists at all.
I agree though that the interaction with the editor window and the find pop-up at this point is fragile. For example, regex mode needs to be enabled explicitly.
All of this of course reinforces the author's point - Helix makes all of this seamless.
For Jetbrains tools, note they use the same keymap on Windows and Linux and there is a keymap option for Mac that is basically the same keymap apart from a few changes to handle OS binding conflicts)
One thing that made me re-try Mac OS after several years of having switched to desktop Linux (due to dissatisfaction with Apple laptop hardware from ~2016 -> 2022) was that I REALLY like the fact that the Mac OS shortcuts work just fine alongside the Jetbrains and IDEAVim key binds that are common with other platforms. So I can select some text using IDEAVim motions, and use command-c to copy or command-x to cut or command-v to replace it with what's on my clipboard. It turns out to be a really comfortable merger of my "programming" muscle memory and my "other computer stuff" muscle memory.
Apple is starting to make me cranky again, and this (plus the affinity apps) is what I'm going to miss next time I switch back to desktop Linux because I don't like the choices they offer me. Though the affinity apps all work on my iPad, and I don't care as much about integration with those.
When I had tried that keymap on macOS, it hadn't felt seamless. I don't remember the problems I had faced though.
In fact, an extension that brings in which key + spacemacs type keybindings in VS Code , and I think IntelliJ too, had provided more cross-platform consistency.
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.
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 keep meaning to check out Helix, but the lack of a GUI makes it a lot harder to adopt. I'm still stuck with Vim, haven't even adopted NeoVim, because of the existence of MacVim. The GUI doesn't need to be fancy, it just needs to exist (and at least try to match platform conventions, e.g. have an actual menubar, normal Cocoa windows, etc). Besides the fact that I want things like full access to the keyboard (including Command key, which isn't generally available to terminal apps), having a GUI app means it plays well with the system window / application management UIs. At any given time I have a bunch of terminal windows, so if my editor is in a terminal too, then it gets bundled with all my other terminal windows in things like the Dock and the cmd-tab app switcher, and I can't bind a system hotkey to jump to my editor.
Helix does have access to the Cmd key in terminals that support it, which I think is pretty much all of the modern ones, like Ghostty, Wezterm, Kitty, iTerm, etc.
Sure, if the terminal doesn't already have that key bound to a menuitem. No terminal editor can use ⌘N for New File because the terminal itself already uses that for New Window, same with ⌘W for Close, or ⌘C for Copy, etc.
I just ran into this the other day with Cmd-h. You actually can make those pass through to the terminal by binding a different key to that menu item in the macOS keyboard shortcut settings. It’s a very janky process: you have to manually name the shortcut to match the actual menu item, in my case “Hide Ghostty.”
In my experience the new user experience and setup with Zed is as barebones as setting up a terminal based editor. The UI around settings & config very basic and you end up on reference doc pages or hunting in github repos if you are outside the golden path.
I hope the overall UX improves in zed as it matures, because I would like to give it a real try someday. Right now it feels like a lot of work if you haven't been using it since the early days.
goimports for Go files don't work out of the box. There are a few issues in the GitHub repo with various fixes (eg. this one), but that's not what I expected when trying out Helix
No support for auto-reloading a buffer when the underlying file changes externally (cf. issue)
No file tree explorer
All in all, considering I'm already very comfortable with (Neo)Vim (and its keybindings), I decided Helix was not for me.
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.
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.
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!
I'm fine with opinionated stuff, so long as the opinions are good! Though in practice I've found most projects who use "opinionated" as a defense to have some gnarly ones...
In all seriousness though, I get your point about text. Everything being text means all your scripting energy goes into text manipulation and the like. What I like in Emacs scripting does come from how easily I can just refer to parts of the UI I'm looking at, its pervasive "current buffer" ideas that usually align with what you want to do (and not cluttering your scripts with getBuffer().context.cursor.position style stuff that other people would prefer... and then things like compile-mode being very good out of the box (so I can lean on that and customize that rather than make a whole new thing)
Emacs has had many decades to figure things out though.
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'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.
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.
Thank you(and the other maintainers) for all the effort!
How is select then act different from vi’s visual mode?
It's basically the same thing. The difference is that in Helix (and Kakoune) you are always have a selection, even when moving with
hjkl, and any actions operate on selections. In contrast with Vi works in a "verb-object" grammar by default, likedwto delete a word. In Helix that would bewd.I also really like helix. It could be my way out of my horribly cursed usage of emacs-with-vim-bindings-but-also-using-some-of-the-emacs keys.
One major issue that makes me uncomfortable with it is that it blindly trusts anything you open in it. https://github.com/helix-editor/helix/issues/2697 describes the issue but I think it's not immediately clear from the issue description that if I can get someone to clone my project and open a file from it in helix, I can run whatever I want on their machine by defining a project-local language server:
then they open a python file in my project, and it adds their machine to my botnet.
There's certainly a significant amount of "yolo" I practically have to do in terms of running new code without reading it in daily life, but I don't really want to expand that to everything I open in my editor, so it's a dealbreaker for exclusive daily use. I also don't think most helix users are aware of how wide open it is.
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-1382831419Interesting 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 actually like the way that vim solves this problem with the quickfix list. The quickfix list is populated by your project-wide search (e.g. builtin
:grepor similar plugins) and then you can just use normal vim commands for every entry in that list, e.g. the search-and-replace example would be a simple:cdo s/foo/baror what I often do is record a macro and replay it across all lines with:cdo norm @q. You can also easily filter the quickfix list with the builtin :Cfilter and if you want to have the immediate live-preview across all files, there is even a plugin for editing the lines being pointed at directly in a buffer, although it's arguably not quite as polished as the UX from Zed.The reason why I like the quickfix feature so much is that it is the same interface being reused for completely different mechanisms. For example it will also be populated by compiler error locations or by much more obscure external tools such as git-jump. Think about any problem that involves source code locations across the entire project, and the quickfix list will probably be the most idiomatic solution in vim.
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-grepRust 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!
How do I get on this?
Assuming you have git and rust installed:
There are some more docs here: https://github.com/mattwparas/helix/blob/steel-event-system/STEEL.md
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.
I've got a lot of love for macros (and also use them on Helix), but there's a few things that I always found hard with them to do.
One of the things that I find tricky is specifically excluding certain things. For example, in the multi-select workflow I can use a keybind to remove all selections that follow a certain pattern. My understanding is that (with a macro workflow) this is much harder, since it amounts to a conditional. The best you can do is performing a highly specific jump at the start of your command, so that you skip over those cases you don't want to edit. (But this always felt very tricky.)
I might be wrong though, I'm absolutely certain there are some dark magic-type macro tricks I just never learned.
Good point.
I'm also not a macro wizard, so I can't confirm either. I guess the general macro answer would be to "try to specify the problem without a conditional, or write a function." If there are better ways to do this on Helix, that's a big thing.
For this that still like vim, but multi-selection, there's vis, which is the happy mix of vim+sam (plan9's editor), which brings structural regex (read multiline) for selections.
In the case of
vis, the author's flow for renaming "foo" would either be to set selections to all strings matching "foo", then change selection to "bar" :Or, to do it interactively:
:x/footo select all occurancecto change selection (like in vim)I used vis for a number of years before switching to Kakoune and eventually Helix. I'm glad to see it's still going! I think this was before Neovim got Lua, Tree-sitter, and LSP support so I'm not sure if I'd still make that switch today but at the time it served me well.
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™.
I'm pretty sure that my dream text editor is some amalgamation of Emacs + helix/kakoune.
Emacs with meow should get most of the way there?
I do use meow with Emacs whenever I try out Emacs, but it's not as snappy as helix or kakoune when it comes to language servers and multiple cursors.
My helix config is similarly small. A third configuration item that I find useful is binding
file_picker_in_current_buffer_directory, especially in projects with deeply nested directories.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 haven't personally tried this yet, but did you use
qmk generate-compilation-databaseto get acompile_commands.jsonand ensure that clangd picks that up?Yes, I have the compile_commands.json file, but something about the cross-compile arguments still cause the LSP to error out in helix for me..
Discovery is so underrated. I feel its reached it top in Windows 98 era, where hotkeys in the menu were clearly marked.
"Modern" applications be like "to activate this feature, shake your phone", "make this gesture", or "just drag in this specific place".
Turns out this post was what it took for me to try this out. The tutor is neat, and coming from Vim, took surprisingly less time to get used to the basic editing flows. And now my vim setup feels ancient in comparison. I specifically like the way diagnostics are handled in helix with floating text at the top but "signs" in the sign column. Basic git markers/signs are nice and unobtrusive.
Glad to hear you're enjoying it so far!
Editors like Vim, Emacs, Helix have an often-overlooked advantage - identical keybindings across OS platforms. In contrast, editors like VS Code and IntelliJ have different (platform-compatible) keybindings for the same function across Linux, Windows, macOS, etc.
What editors like VS Code do give you is:
In my experience, use cases involving flat-level multi-cursor selection are fairly replicable in VS Code.
Take the first example in the post:
%. This selects the entire file.s. This opens a ‘select’ input field in the command bar.foo. This will narrow down your current selection to only select all matches offoo. In other words, you now have every match offooin your file selected.c. This replaces each selection with a cursor, and puts you into insert mode.bar. You’re editing all instances at the same time.In VS Code on Linux, I would do it as follows:
Ctrl-F. This opens the Find interface.foo, then pressAlt-Enter. Each instance offoowill be selected across the file, with a cursor put after each selection.bar. You're editing all instances at the same time.I think VS Code can even replicate Helix's
Sfunction to some extent - split selections further into sub-selections with a regex match.But, inverting selection (Alt-K in helix) isn't possible in VS Code without some extension if it exists at all.
I agree though that the interaction with the editor window and the find pop-up at this point is fragile. For example, regex mode needs to be enabled explicitly.
All of this of course reinforces the author's point - Helix makes all of this seamless.
For Jetbrains tools, note they use the same keymap on Windows and Linux and there is a keymap option for Mac that is basically the same keymap apart from a few changes to handle OS binding conflicts)
One thing that made me re-try Mac OS after several years of having switched to desktop Linux (due to dissatisfaction with Apple laptop hardware from ~2016 -> 2022) was that I REALLY like the fact that the Mac OS shortcuts work just fine alongside the Jetbrains and IDEAVim key binds that are common with other platforms. So I can select some text using IDEAVim motions, and use command-c to copy or command-x to cut or command-v to replace it with what's on my clipboard. It turns out to be a really comfortable merger of my "programming" muscle memory and my "other computer stuff" muscle memory.
Apple is starting to make me cranky again, and this (plus the affinity apps) is what I'm going to miss next time I switch back to desktop Linux because I don't like the choices they offer me. Though the affinity apps all work on my iPad, and I don't care as much about integration with those.
When I had tried that keymap on macOS, it hadn't felt seamless. I don't remember the problems I had faced though.
In fact, an extension that brings in which key + spacemacs type keybindings in VS Code , and I think IntelliJ too, had provided more cross-platform consistency.
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: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
iexintegration.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-lsin your$PATHand maybe setting[language-server] elixir-ls = { config = { elixirLS.dialyzerEnabled = true } }in yourlanguages.tomlif you want to see errors from Dialyzer.I keep meaning to check out Helix, but the lack of a GUI makes it a lot harder to adopt. I'm still stuck with Vim, haven't even adopted NeoVim, because of the existence of MacVim. The GUI doesn't need to be fancy, it just needs to exist (and at least try to match platform conventions, e.g. have an actual menubar, normal Cocoa windows, etc). Besides the fact that I want things like full access to the keyboard (including Command key, which isn't generally available to terminal apps), having a GUI app means it plays well with the system window / application management UIs. At any given time I have a bunch of terminal windows, so if my editor is in a terminal too, then it gets bundled with all my other terminal windows in things like the Dock and the cmd-tab app switcher, and I can't bind a system hotkey to jump to my editor.
Helix does have access to the Cmd key in terminals that support it, which I think is pretty much all of the modern ones, like Ghostty, Wezterm, Kitty, iTerm, etc.
Sure, if the terminal doesn't already have that key bound to a menuitem. No terminal editor can use ⌘N for New File because the terminal itself already uses that for New Window, same with ⌘W for Close, or ⌘C for Copy, etc.
I just ran into this the other day with Cmd-h. You actually can make those pass through to the terminal by binding a different key to that menu item in the macOS keyboard shortcut settings. It’s a very janky process: you have to manually name the shortcut to match the actual menu item, in my case “Hide Ghostty.”
Zed is apparently adding support for Helix keybinds, so maybe that's an option?
In my experience the new user experience and setup with Zed is as barebones as setting up a terminal based editor. The UI around settings & config very basic and you end up on reference doc pages or hunting in github repos if you are outside the golden path.
I hope the overall UX improves in zed as it matures, because I would like to give it a real try someday. Right now it feels like a lot of work if you haven't been using it since the early days.
Where did they mention this?
found it https://github.com/zed-industries/zed/discussions/33580
Things I don't like:
goimportsfor Go files don't work out of the box. There are a few issues in the GitHub repo with various fixes (eg. this one), but that's not what I expected when trying out HelixAll in all, considering I'm already very comfortable with (Neo)Vim (and its keybindings), I decided Helix was not for me.
Cool project though!
Lots of good tips in there to level up my Helix usage. Helix is best when using it looks like magic to somebody else.
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
This is quite interesting. If Helix's keybindings make a lot of sense, I hope someone can give me an
evil-helix-modefor 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
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!
I'm fine with opinionated stuff, so long as the opinions are good! Though in practice I've found most projects who use "opinionated" as a defense to have some gnarly ones...
In all seriousness though, I get your point about text. Everything being text means all your scripting energy goes into text manipulation and the like. What I like in Emacs scripting does come from how easily I can just refer to parts of the UI I'm looking at, its pervasive "current buffer" ideas that usually align with what you want to do (and not cluttering your scripts with
getBuffer().context.cursor.positionstyle stuff that other people would prefer... and then things likecompile-modebeing very good out of the box (so I can lean on that and customize that rather than make a whole new thing)Emacs has had many decades to figure things out though.
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.
https://github.com/MagicDuck/grug-far.nvim
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!
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.