I’m in a very similar situation: I switched from mostly using VS Code and vim to Helix and now I kinda want Helix with a more IDE-like experience. Now, I’m reading this and I’m thinking… Do we yearn for Emacs?
I’ve been using lazyvim as a low-config neovim IDE setup for a while now.
I’ve used Doom Emacs, which aims to do the same for emacs, but I found that the moment you need to step off the beaten path with Doom it takes a lot of work to get anything done. I’ve not had that trouble with lazyvim - lua is pleasant (more than elisp, at least) and the community is much bigger so I can usually find a recipe or a plugin.
Elisp isn’t my cup of tea, which is a big reason I left Emacs. Lua is more pleasant, even if it is far from perfect.
It seems that Helix will adopt Scheme as its plugin system. Perhaps this will eventually attract many Emacs users, but I am sure many users will frown upon a Lisp
(https://www.reddit.com/r/neovim/comments/1bdoj2z/helix_is_getting_lisp_plugin_system/)
LOL! The children do apparently yearn for the terminal, at least. Emacs is a non-starter for me, but I respect it. I also respect the people who stitch together their own idiosyncratic but comprehensive kakoune workflows.
I guess I’m just looking for something more “powerful” than Sublime, but that I don’t need to configure or customize too much. I already have the multi-cursor mindset and can’t imagine going back from that.
In case long configurations are scaring you away from trying Emacs, please consider that modern Emacs is very nice with pretty minimal settings. I have been using Emacs for more than 15 years and my configuration keeps shrinking. It’s barely 30 LOC of trivial variable assignments. It could be even shorter if some defaults were not a bit antique.
I guess I’m just looking for something more “powerful” than Sublime, but that I don’t need to configure or customize too much. I already have the multi-cursor mindset and can’t imagine going back from that.
You say Emacs is a non-starter but Doom Emacs requires 0 configuration and has multiple cursors.
That’s why I’m hoping that Zed is going to be that. It’s already working pretty nicely. I believe it has a bit more to go to be ready for prime time, but it’s looking good.
A funny question! I assume it’s rhetorical, but… if you’re not allergic to lisp or configging, maybe. The traveler’s backpack is a bit heavier to lift at first, and perhaps a bit heavier to carry sometimes, but the tools inside eventually fit your hands and mind just so. Plus, magit and org mode are fun if you think stuff like magit and org mode are fun.
I’d like to add onto this my unabashed love for Helix. I’ve been steeped in the terminal for almost two decades now but Vim was too big a pill to swallow, and Neovim was too demanding of configuration (and installation difficulties).
I have little to add other than, “If you’ve been vimcurious, try out Helix.” Seriously! If you’re someone who wanted to get into Vim but never could, this is your call to try out Helix.
I relate a lot to the author. Helix’s big advantage for me is that I can do big edits easily and programmatically with multiple-cursors and macros, which I would previously do with Python script (or manually).
Great writeup! Although I don’t really have any serious complaints with my current editor setup, I’ve recently been tempted to give Helix a try, and this makes me want to even more. Maybe I can find some time over the holidays.
Mouse interaction is theoretically possible, but severely limited.
More than anything else, this has been what keeps me from adopting a terminal editor as my primary. Mouse-based selection is just so much faster for me than anything else I’ve tried. I see Helix has a “mouse mode” setting in the config docs, but it’s just a boolean. Do you use mouse selection in your workflow? What’s it like?
I’m not sure if I have that specific setting enabled, but I’m able to make arbitrary selections with my mouse no problem. The selection -> filter -> action workflow I find really satisfying.
For selecting with the mouse you can do it two ways (that I’m aware of):
In normal mode: click and drag to select a range
click somewhere, enter visual mode, click somewhere else
At that point you can treat it like any other selection.
I think the main downside I’ve noticed after switching to Helix from VS Code is that it’s easier to browse in VS Code because Helix has no built-in file browser.
I find the <space>f and <space>F filtering browsers quite adequate, along with <space>/ (often prefilling the query with * on a selection) and then using filters for project-wide search. (You can separate filters in the file listing dialog with spaces and use ! to negate a part.) Not 100%, but so far plenty even on quite large projects.
If you want to try Helix in earnest, I advise forgetting that you have a mouse or trackpad. There’s no workflow in a TUI like Helix that’s made faster with a pointing device.
To get the most mileage out of trying Helix, keep the official keymap handy for a few days while you work and make a concerted investment in learning the key bindings for your primary workflows.
After that, you’ll either have no interest in your mouse, or no interest in using Helix. Either way, you’ll have learned something new and probably won’t have much to regret.
It can be. The degree of frustration is proportional to two things. 1. general comfort with/investment in life in the terminal and 2. degree of investment in learning keybindings for core workflows.
Too little of either and it’ll no doubt be frustrating. Not wanting either is also a valid choice of course; in which case, there’s nothing wrong with GUI editing!
The unsaid upside of doing more in the terminal is control. CLI and TUI creators understand that keybindings are essentially the user’s API to their software, and so keybindings are treated with commensurate respect. Bindings don’t go missing, get removed, or changed on a whim, as controls do in GUIs. You also tend to start building config files that reflect your preferences/preferred defaults, and you carry them around from system to system, and of course get revision controlled. These accumulate, and lead to a lot of user control that’s hard to find in GUI software.
I can make selections with the mouse and there are some other things I can click or do with the mouse, so I assume mouse mode is on by default. But practically speaking, I almost never use it. If I’m in the text editor, it’s almost always easier to do everything with the mouse.
That said, I do sometimes want to just browse things in a more exploratory way, and I find that’s often a lot easier with a mouse alone. And that’s the sort of place where these sorts of tools always feel a little bit painful to use.
Browsing through large-ish projects trying to understand how things work is, not gonna lie, probably most of where my editor time goes, although it’s usually interleaved with writing or refactoring workflows. If I can click to jump to call sites or definitions, and mouse selection and scroll works, that’s probably good enough for me. I am open to learning new ways of doing this, but I’ve been pointing and clicking since I was a kid, so it’s pretty deeply engrained.
The lack of an integrated file tree browser is another thing that makes me hesitate, but I can imagine getting comfortable with an external TUI file-browser workaround.
I use the mouse with Helix regularly and have no problems! And I think it’s enabled by default. I use it regularly in Gnome Terminal, iTerm2, Termux, and Blink.
It works just as expected. It can be difficult to copy to clipboard on some terminal emulators over SSH; locally, I just use :clipboard-yank (or :cy for short).
I kept the keymap documentation open, and every time I thought “there must be an easier way to do this”, I’d look through the documentation page to see if I could find something that made sense.
Nice to be aware of the command pallette - space + ?
Good shout! I only realised the other day that it actually showed the shortcuts in that view. That said, I think the keymap documentation is a bit more useful for being categorised — I can guess more easily where I might find the thing I’m interested and start looking for it. This is useful when getting started if you know what you want but you don’t necessarily know what it might be called in Helix-land.
That said, now I’m more comfortable with the concepts and terminology, the command palette will probably be a lot more useful.
Anyone knows if Helix haa regex search and replace?
I know there is the multi-cursor feature where you make a selection, press s, then type the search term which can be a regex, then press enter. This spawns a cursor at each search match which can then be edited simultaneously.
But I would love if there was the ability to capture groups and use them during the replacement step. Like in vim you can use \1, etc. for using captured groups.
I feel a lot of the times you can replicate this functionality using clever cursor movements and commands but my brain can comprehend regex search and replace a lot better.
I really like Helix, but I’ve also managed to get hooked on outline notetaking that relies heavily on indetation-based text folding, and Helix has no folding support yet, so I’m stuck on Neovim for the time being.
Great article! However, I’ve been using helix as my editor for over a year now, and this article doesn’t mention my favorite feature: seamless multicursor.
It’s so nice to press C and have a second cursor right below where I was previously. It’s also nice to be able to highlight some block of text, press s followed by my search term followed by enter, and have a cursor at each instance of that text.
It’s incredibly powerful and the reason I can’t go back to vim (vim’s plugins don’t do as good of a job IMO). I never want to go back to vim macros now that I’ve had this. Sublime and VS Code obviously have good support for multicursor as well.
Yeah, I think multicursor for me is almost too obvious to mention because I’m familiar with it from Sublime/VSCode, but yeah, it’s definitely really useful. It took a while at first to get used to creating new cursors via splitting a selection (or just creating a second cursor as you say), but it’s also a much more powerful way of creating new cursors than the typical Ctrl-D mechanism.
Whoops, sorry, that should be something like “as opposed to navigating to it manually”, i.e. by clicking through folders. I’ll fix that this evening at some point.
I’m in a very similar situation: I switched from mostly using VS Code and vim to Helix and now I kinda want Helix with a more IDE-like experience. Now, I’m reading this and I’m thinking… Do we yearn for Emacs?
I really want an absolutely minimal text editor that integrates well with the shell.
I’ve written several, but this next one is going to be the one, I think. If I ever get time to work on it again.
I used vis for a while and I’d describe it as pretty much that. Too minimal for me, though.
I’d like to see that :)
If you want to avoid scraping stdout of the shell, Oils has a more structured protocol over a Unix domain socket, i.e. “headless mode” - https://lobste.rs/s/ineb98/ghostty_1_0_is_coming#c_fb1rw7
I’ve been using lazyvim as a low-config neovim IDE setup for a while now.
I’ve used Doom Emacs, which aims to do the same for emacs, but I found that the moment you need to step off the beaten path with Doom it takes a lot of work to get anything done. I’ve not had that trouble with lazyvim - lua is pleasant (more than elisp, at least) and the community is much bigger so I can usually find a recipe or a plugin.
+1. I migrated my entire workflow from Doom Emacs to neovim a while ago, too. https://maskray.me/blog/2024-11-02-tinkering-with-neovim
Elisp isn’t my cup of tea, which is a big reason I left Emacs. Lua is more pleasant, even if it is far from perfect. It seems that Helix will adopt Scheme as its plugin system. Perhaps this will eventually attract many Emacs users, but I am sure many users will frown upon a Lisp (https://www.reddit.com/r/neovim/comments/1bdoj2z/helix_is_getting_lisp_plugin_system/)
LOL! The children do apparently yearn for the terminal, at least. Emacs is a non-starter for me, but I respect it. I also respect the people who stitch together their own idiosyncratic but comprehensive kakoune workflows.
I guess I’m just looking for something more “powerful” than Sublime, but that I don’t need to configure or customize too much. I already have the multi-cursor mindset and can’t imagine going back from that.
In case long configurations are scaring you away from trying Emacs, please consider that modern Emacs is very nice with pretty minimal settings. I have been using Emacs for more than 15 years and my configuration keeps shrinking. It’s barely 30 LOC of trivial variable assignments. It could be even shorter if some defaults were not a bit antique.
Same BUT it took me years to find the right 30 LOC!
You say Emacs is a non-starter but Doom Emacs requires 0 configuration and has multiple cursors.
TIL Doom Emacs, thanks! It’s not for me though. These are not the keybindings I’m looking for.
One day someone will fork doom and make it go meow
That’s why I’m hoping that Zed is going to be that. It’s already working pretty nicely. I believe it has a bit more to go to be ready for prime time, but it’s looking good.
I want to use Zed but it seems I have to use Cursor to keep up with the times.
Maybe, but I’m not willing to admit that yet.
A funny question! I assume it’s rhetorical, but… if you’re not allergic to lisp or configging, maybe. The traveler’s backpack is a bit heavier to lift at first, and perhaps a bit heavier to carry sometimes, but the tools inside eventually fit your hands and mind just so. Plus, magit and org mode are fun if you think stuff like magit and org mode are fun.
I think meow is helix-y.
Regardless, good write up and conversation.
I’d like to add onto this my unabashed love for Helix. I’ve been steeped in the terminal for almost two decades now but Vim was too big a pill to swallow, and Neovim was too demanding of configuration (and installation difficulties).
I have little to add other than, “If you’ve been vimcurious, try out Helix.” Seriously! If you’re someone who wanted to get into Vim but never could, this is your call to try out Helix.
I relate a lot to the author. Helix’s big advantage for me is that I can do big edits easily and programmatically with multiple-cursors and macros, which I would previously do with Python script (or manually).
Great writeup! Although I don’t really have any serious complaints with my current editor setup, I’ve recently been tempted to give Helix a try, and this makes me want to even more. Maybe I can find some time over the holidays.
More than anything else, this has been what keeps me from adopting a terminal editor as my primary. Mouse-based selection is just so much faster for me than anything else I’ve tried. I see Helix has a “mouse mode” setting in the config docs, but it’s just a boolean. Do you use mouse selection in your workflow? What’s it like?
I’m not sure if I have that specific setting enabled, but I’m able to make arbitrary selections with my mouse no problem. The selection -> filter -> action workflow I find really satisfying.
For selecting with the mouse you can do it two ways (that I’m aware of):
At that point you can treat it like any other selection.
I think the main downside I’ve noticed after switching to Helix from VS Code is that it’s easier to browse in VS Code because Helix has no built-in file browser.
I find the
<space>fand<space>Ffiltering browsers quite adequate, along with<space>/(often prefilling the query with*on a selection) and then using filters for project-wide search. (You can separate filters in the file listing dialog with spaces and use!to negate a part.) Not 100%, but so far plenty even on quite large projects.If you want to try Helix in earnest, I advise forgetting that you have a mouse or trackpad. There’s no workflow in a TUI like Helix that’s made faster with a pointing device.
To get the most mileage out of trying Helix, keep the official keymap handy for a few days while you work and make a concerted investment in learning the key bindings for your primary workflows.
After that, you’ll either have no interest in your mouse, or no interest in using Helix. Either way, you’ll have learned something new and probably won’t have much to regret.
Fair enough! Definitely something to experiment with on my own time, though: it sounds pretty frustrating and slow to get started with.
It can be. The degree of frustration is proportional to two things. 1. general comfort with/investment in life in the terminal and 2. degree of investment in learning keybindings for core workflows.
Too little of either and it’ll no doubt be frustrating. Not wanting either is also a valid choice of course; in which case, there’s nothing wrong with GUI editing!
The unsaid upside of doing more in the terminal is control. CLI and TUI creators understand that keybindings are essentially the user’s API to their software, and so keybindings are treated with commensurate respect. Bindings don’t go missing, get removed, or changed on a whim, as controls do in GUIs. You also tend to start building config files that reflect your preferences/preferred defaults, and you carry them around from system to system, and of course get revision controlled. These accumulate, and lead to a lot of user control that’s hard to find in GUI software.
I can make selections with the mouse and there are some other things I can click or do with the mouse, so I assume mouse mode is on by default. But practically speaking, I almost never use it. If I’m in the text editor, it’s almost always easier to do everything with the mouse.
That said, I do sometimes want to just browse things in a more exploratory way, and I find that’s often a lot easier with a mouse alone. And that’s the sort of place where these sorts of tools always feel a little bit painful to use.
Browsing through large-ish projects trying to understand how things work is, not gonna lie, probably most of where my editor time goes, although it’s usually interleaved with writing or refactoring workflows. If I can click to jump to call sites or definitions, and mouse selection and scroll works, that’s probably good enough for me. I am open to learning new ways of doing this, but I’ve been pointing and clicking since I was a kid, so it’s pretty deeply engrained.
The lack of an integrated file tree browser is another thing that makes me hesitate, but I can imagine getting comfortable with an external TUI file-browser workaround.
I use the mouse quite frequently with Helix and I don’t have any complaints. Clicking and selecting stuff works fine.
I use the mouse with Helix regularly and have no problems! And I think it’s enabled by default. I use it regularly in Gnome Terminal, iTerm2, Termux, and Blink.
It works just as expected. It can be difficult to copy to clipboard on some terminal emulators over SSH; locally, I just use
:clipboard-yank(or:cyfor short).Every time I learn how to do something with a couple of keypresses in hx I feel like a wizard. Never had that with vim.
I moved from Emacs to Neovim and I like it a lot. But I will probably move to Helix once the script support lands.
Nice to be aware of the command pallette -
space + ?Good shout! I only realised the other day that it actually showed the shortcuts in that view. That said, I think the keymap documentation is a bit more useful for being categorised — I can guess more easily where I might find the thing I’m interested and start looking for it. This is useful when getting started if you know what you want but you don’t necessarily know what it might be called in Helix-land.
That said, now I’m more comfortable with the concepts and terminology, the command palette will probably be a lot more useful.
This is siiiiick. I love the little keymap hint in the list. TIL
[gand]g, I wish it would span buffers though?Anyone knows if Helix haa regex search and replace?
I know there is the multi-cursor feature where you make a selection, press s, then type the search term which can be a regex, then press enter. This spawns a cursor at each search match which can then be edited simultaneously.
But I would love if there was the ability to capture groups and use them during the replacement step. Like in vim you can use \1, etc. for using captured groups.
I feel a lot of the times you can replicate this functionality using clever cursor movements and commands but my brain can comprehend regex search and replace a lot better.
I really like Helix, but I’ve also managed to get hooked on outline notetaking that relies heavily on indetation-based text folding, and Helix has no folding support yet, so I’m stuck on Neovim for the time being.
Folding, spell checking, minimap, context indicator. 4 features I’m waiting for. But still a delight to use.
Great article! However, I’ve been using helix as my editor for over a year now, and this article doesn’t mention my favorite feature: seamless multicursor.
It’s so nice to press C and have a second cursor right below where I was previously. It’s also nice to be able to highlight some block of text, press s followed by my search term followed by enter, and have a cursor at each instance of that text.
It’s incredibly powerful and the reason I can’t go back to vim (vim’s plugins don’t do as good of a job IMO). I never want to go back to vim macros now that I’ve had this. Sublime and VS Code obviously have good support for multicursor as well.
Yeah, I think multicursor for me is almost too obvious to mention because I’m familiar with it from Sublime/VSCode, but yeah, it’s definitely really useful. It took a while at first to get used to creating new cursors via splitting a selection (or just creating a second cursor as you say), but it’s also a much more powerful way of creating new cursors than the typical Ctrl-D mechanism.
What does this mean?
Whoops, sorry, that should be something like “as opposed to navigating to it manually”, i.e. by clicking through folders. I’ll fix that this evening at some point.
[Comment removed by author]
I think this unfortunately ended up on the wrong post (likely Lobsters bug).
Thank you!!