When I was in high school I found Sublime Text and learned “multiple cursors”. Since then, I’ve transitioned to vscode, mainly because I need LSP (without too much configuration work) for my work.
I keep hearing about how modal editing is faster and I would like to switch to a more performant editor. I’ve been looking at helix, as the 4th generation of the vi line of editors. Is anyone using it? Is it any good for the main code editor?
The problem that I have is that learning new editing keybindings would probably take me a month of time, before I get to the same amount of productivity (if I ever get here at all). So I’m looking for advice of people who have already done that before.
My code editing does involve a lot of “ctrl-arrow” to move around words, “ctrl-shift-arrow” to select words, “home/end” to move to beginning/end of the line, “ctrl-d” for “new cursor at next occurrence”, “shift-alt-down” for “new cursor in the line below”, “ctrl-shift-f” for “format file” and a few more to move around using LSP-provided “declaration”/“usages”.
I would have to unlearn all of that.
Also, I do use “ctrl-arrow” to edit this post. Have you changed keybindings in firefox too?
I use Helix
TLDR: Yes I think helix is worth trying out. It has some missing features but it is an amazing piece of software.
Yes I use helix daily. It is very fun to use and you can do many things faster. It is particularly good when navigating a (large) codebase you know fairly well. You are able to jump around and find/edit relevant code very quickly.
Compared to vs code:
- it is much faster and more minimal
- It might be harder to get things up and running than in vs code, e.g. to get auto-completion working in helix you need to have the LSP for that language installed. It can be a bit confusing if you have never done it before but it is easy once you have done it a few times.
Compared to neovim I think it is:
- easier to learn
- slightly faster - especially with large files
- you will have a much smaller/simpler configuration. AFAIK Helix has more features working out of the box than neovim (file picker, lsp support ect) and needs less configuration to get things to a workable state.
The downside of helix compared to both neovim and vscode is that it does not have plugin support yet so you will need to use other tools in combination with it to get an equivalent experience. Here are some tools that are commonly used with helix:
- yazi - terminal file manager
- gitui or lazygit - terminal git user interface
- zellij - terminal pane manager
Helix really shines when:
- performance matters - I have edited files with millions of lines and had no trouble on codebases where my colleagues IDE’s become very slow.
- You want to use multiple cursors at times
- You want a simple or no configuration
- It is taking too long to learn the vim keybindings - vim keybindings are more concise but less intuitive and harder to learn
I recommend you use the tutor (
hx --tutor) for a few minutes each day to learn the keybidings.Thanks for the overview. I’ll work with tutor and see how frustrated I get :D
Regarding language servers:
Recently, I got into this philosophy of “every project needs a declarative environment”. It means that there is a committed file that should contain all tooling need to work with the project. Compilers, formatters, test runners and also: language servers.
This fights with vscode extensions which try to be clever and download their language server / bundle it into the extension itself. “No, rust-analyzer, I don’t want your build because it does not work with xtensa target arch I’m using in this project”.
So actually, this ties nicely with helix not providing the language servers itself, but allowing you to bring your own.
I’ve recently taken to kakoune which was one of the inspirations for Helix.
It’s not as fancy (in terms of built-in features) out of the box, but it’s very performant, integrates with tmux well, and for the C++ and Python I’m writing I haven’t felt the need for much beyond token based word completion and grep.
The client server model it uses has really let me improve my tmux skills because I’m working inside of it more and using it for editor splits.
I don’t know if Helix does this, but I’ve also come to love the pipe operator (where you just pipe a selection into some external program and the selection gets replaced with the output, so you can use the e.g. the sort command to sort text). You can also pretty easily add in custom extensions via command line programs.
Ahhh nice, I have thought about trying out Kakoune as it supports plugins. Do you use many plugins/find them useful?
Helix does have a pipe command also.
I’ve mostly just tweaked the configuration and built my own comment formatter/reflow command based on the comment style at work.
It’s almost more about what it doesn’t have for me, because what I’ve run into a lot with trying newer editors is they try and manage the code too much and the code base at work has its own style guide that doesn’t match what the editor tries to do. So the editor might make me slightly more productive … until I find myself fighting with it every 3 lines because of auto formatting or some language server quirk.
I happily use Helix for Rust, etc projects, and as a general editor. I switch back to VSCode for TypeScript/Svelte projects because the plugins make it more productive for me. I do miss the editing experience and need to check if there’s a VSCode plugin that lets me not confuse my muscle memory.
Helix was the thing that finally made me remap my caps lock key to
esc.
Helix is absolutely wonderful.
Used to use Vim/Neovim, but the hassle of setting it up and maintaining huge configuration files was a pain (for me).
Also I never really got it working the way I wanted and never had LSP working for all the languages I needed.
Helix on the other hand. My config file is under 20 lines, LSP works super for all my needs. Well thought out keybindings (mostly) and overall a joy to use.
Nice features and fast.
Still a bunch of things missing, it is a rather young piece of software, but I have been using it as my only editor for the last 1 1/2 years.
Yeah, keybindings are well thought out. The most off-putting thing of default vim is that there are about 5 different “delete” commands. One for a character, one for the whole line, one for selected text, one for end of line. In helix, this is all just “delete selected text” and then “x” is for selecting a line. Make so much more sense.
Throughout my career, I have used (in no particular order)
- Eclipse (as Android Studio)
- IntelliJ (as Android Studio)
- SublimeText
- VS Code
- IntelliJ (as IntelliJ)
- various CLI editors when sshing into servers (vim, nano, a few others)
Switching your muscle memory takes a long time, which is why you have things like spacemacs, or different keybind presets for almost all of these editors.
There is more value in understanding how to extend and customize your editor than in searching for a new one. Use whatever your workplace provides the best support for, and then customize it from there.
There is more value in understanding how to extend and customize your editor than in searching for a new one. Use whatever your workplace provides the best support for, and then customize it from there.
I think there’s something to be said for shaking up your environment periodically as well and trying new things. Sure, there’s a week where you edit at a snails pace, followed by a month where you edit a bit slower than normal, but different tools really do have different pros and cons.
For the code bases I’ve worked in, this evolved from necessity as the code files were so large many editors were struggling, the rules for the style so custom that editors can’t be properly configured to match, or the editor performance in general was questionable.
I went through a journey of sorts from IDEs to Electron based editors to Emacs and currently am working with Kakoune (and I’ve passed over a bunch of other editors like Sublime, Helix, and Zed that couldn’t meet my requirements or didn’t match my sensibilities – even though a thing or two here or there really was excellent). Pretty much every change has been the result of the editor pain points that couldn’t be addressed without actually working on the editor itself.
Depends on what device I’m using. On my tower(s), I’m typically reaching for Rider, Pycharm, or Zed. On my laptop(s) it’s pretty much always Helix or Zed. On servers it’s vim 100% baby. I’ve gotten pretty comfortable working with theses tools, so I haven’t really needed to look into alternatives at all.
Is the lack of debugger in Zed not a problem for you?
Nah. When I’m using Zed it’s typically for Elixir/Erlang and I’m usually run debugging tools outside of Zed in a separate shell. When I’m using
iexand/orobserverI like to use a full screen terminal on a separate workspace/tab than the editor itself
I used to use vim but imo it’s not worth the time it requires to configure to get working properly. These days I don’t code without a debugger so if there’s not a good way to set breakpoints I don’t even start
Most code I write is Java and I use IntelliJ for that. When I write Python I use PyCharm, anything else, Visual Studio Code or VSCodium.
All of these have plugins for vim keybindings which are always the first thing I install. I almost never disable them.
I switched to and exclusively used vim for about a year. I switched back to Sublime one day, and found I was like 10x more productive and comfortable.
Just use the editor you like. There’s no right or wrong answer!
… And btw, Sublime 4 has improved LSP support. Just install the base LSP plugin + plugins for the languages you want. Some even give the option to install the LSP server automatically if if’s not detected.
VS Code with your favorite plugins is pretty fantastic for any editing in my experience. I’ve tried others and they do seem to work well, but not well enough to warrant switching, and they often come with quirks that are just annoying enough to make me want to switch back.
I suggest trying others to know what’s out there, even if you ultimately end up back on VS Code.
I’ve moved on from vim to neovim, and I think I’ll continue using something in that family in the future. It’s a pretty stable experience overall, but the inclusion of LSPs and tree-sitter have been good improvements too.
Ultimately editors are tools, similar to keyboards, os-es, screens, chairs, shoes and so on. There are some objective quality differences between a well-constructed tool and some slapdash nonsense, and there are a huge amount of subjective quality differences. What suits me may not suit you, and vice versa.
It’s generally good to try out some new (to you) stuff and see if you like it. If you do, great; if you don’t, well, now you know. I think my worst experience was with Acme (or Wily? can’t remember), during a phase where I experimented with Plan 9 stuff. Ultimately very not my cup of tea, but apparently Rob Pike (who made it) and some other gophers still enjoy it? Which is good for them, just like it’s good for me that I can choose not to use it. It’s just personal tastes, and I still think it’s good that I gave it a go.
The debate over holding down modifier keys vs modes is also a part of the Emacs vs vi debate from many decades ago. There might be some statistics for what works best for the most people now, but again, use what suits you. And try some new stuff when you get curious, it’s generally good for you.
Vscode. I am surprised to see a lot of people still use sublime text. I was a long hold out on that one but it’s just so much worse than vscode in every way.
nano is the best (imho) for up to medium size files. It’s preinstalled in most Linux boxes , it’s simple and flexible enough, takes a minimal amount of time to learn basic for keys and then use them all the time
You should check out Micro. It’s a slightly more sane alternative to nano:
I use JetBrains Rider for dotnet (with Vim emulation), VS Code for general misc code editing (with Vim emulation), and NeoVim for quick in-terminal edits and Git workflows. I even have vi-mode enabled in my terminals, but I haven’t bothered trying to do it in browser yet.
My experience is that modal editing is only a little faster, but it’s much more comfy, even fun! I enjoy coding with modal editing much more so than modeless. Being able to zip around the code without having to move my fingers to the arrow cluster just feels nice.
Don’t Speculate
Go to Twitch/YouTube. Watch a senior Vim/Jetbrains/Emacs/VS Code/Helix churn out code for a hackathon/advent-of-code, and see what you are (or are not!) missing out on.
If you have “how the hell did they just do that” moments, figure out what that feature is, and STEAL IT. If its too hard to steal, then you are probably being limited by your editor.
- If you’re going to try modal editors, sooner is exponentially better. Probably start with Vim bindings for VS Code.
- If you’re not going to go modal, then make absolutely sure you don’t bottom out. To be frank, Ctrl+D is the tip of the iceberg. Half the benefit of modal editors is, mastery is mandatory; they chase you around with a 10k volt taser until you’ve got 100 instinctual shortcuts. Hardly anyone mentions this but Go beyond/outside your editor: At the OS level, use spacebar as a modifier key, where holding spacebar converts your WASD into arrow keys. Then disable your normal arrow keys. Something like that will get you vim-like benefits, but in every app, and without a learning bump instead of a learning mountain. For VS Code, get cursor jumper extensions like Mario (block jumper), get cursor-alignment extensions, write boatloads of custom code snippets, get a macro record+replay extension, make a jump-to-next quote, jump to next bracket, install sequential number generator extension, a case change (camel case, snake case, etc) extension, sort lines, case-preserving rename. If you can avoid bottoming out, and keep learning, you’ll likely never feel that you are missing out on whatever modal editor people are swearing by.
I get this, but an IDE should be invisible and grow as you do and not require you to learn lots of janky things before it becomes a little bit useful for you.
Need the basics, great, here they are. Don’t understand some advanced feature? Well the IDE has it here, but it isn’t in your way, mess with it as and when you want. It’ll still be there.
I don’t think one IDE does everything for different languages and its ok to swap editors depending on your workflow, your project and your ever-changing skillset.
I get this, but
Why not say “I get this, and …” ?
I don’t think the idea of a learn-as-you-go editor goes against the idea of watching skilled devs with their favorite tool
VSCode with the Vim plugin most of the time. Vim if I’m just editing something small and was already in a terminal.
Every IDE worth trying has Vim mode or a plugin for it, you don’t need to use actual Vim to benefit from it!
+1 for Helix. Selection then action always made more sense to me than action then selection.
