Workflow: Why Vim, Why Not

So I’m thinking of summarizing the research coding workflow I use now into a couple of blog posts here. Hopefully by having a moment of reflection and writing, I can get a better understanding of how I do things and perhaps even give people some cool ideas.

So the very first one in the sequel is gonna be about editors. This topic apparently sometimes can get really controversial, so I’ll be just focusing on my personal experience and feelings of how me using my personal favorite coding tools changes my coding mindsets, and alleviates my pain from the repetitive coding tasks.

After all, I don’t believe anyone would actually miss a project deadline because of not using editor X.

A bit of prologue

Before anything else, it’s worth mentioning that when I writes “vim”, unless explicitly specified, I’m likely referring to the keybindings instead of the text editor. Vim, as a terminal-based editor, might not be for everyone, and I personally don’t use it unless necessary for certain tasks. On the contrary, vim keybinding is more of a universal concept – it exists in many other editors/IDEs such as neovim, emacs, vscode, and intellij, either natively or as a plugin. You can even find vim keybindings inspired browser extension. The keybinding is what makes vim the editor stand out, and it’s really the keybinding that shapes my coding habits and mindsets these days. Therefore I will make the vim keybinding the primary of the discussion here.

Traveling back in time a bit, I try to recall how I started with vim. Unfortunately, the exact time and reason are a kind of blur – just remember it was somewhere during the first or second year in uni. What I do remember is, it wasn’t the most pleasant experience in the very beginning (looking at you – HJKL for cursor movement). But after the “survival period”, it gets more and more enjoyable as the proficiency and knowledge increment. It just feels good when I no longer need to have my hands dance back-and-forth between my keyboard and mouse. Even until today, I still think it’s one of the things that has steep learning curve but really pays off in the long-run.

So, why vim?

One point about editing and has been said many and many times is that we need right tools tailed to the tasks. Code editing is no different. There are so many editing operations you would do only when coding, such as “remove the content between a pair of double quotes”, “adding/removing ‘#’ to the beginning of N lines”, or “adding import statements in the beginning of the file and jump back”.

When these movements are extraordinarily frequent, it naturally makes sense to have a keybinding geared towards these movements to improve the overall efficiency. It’s a good point, but the thing is vim isn’t the only keybinding that does that. All the keybindings out there are probably designed with this idea in mind, from popular ones like vscode and emacs to niche ones jammed together by some geeky programmers for themselves over a boring weekend.

Lots of articles talking about the upsides of vim sound like they assume the alternatives are something like MS Notepad. It might be a good pitch to someone just learn programming, or to someone who hasn’t thought about this and just clicking around their code to make edits. But to a person who has some experience and decently exposed to some shortcuts in their code editors, this is gonna be a harder sell.

So, again, why vim?

Overall, it’s the composability of the vim keybinding. Vim chooses a small set of atomic operations triggered by single key strokes, such as “d” for delete, “j” for cursor go to next line, “G” for cursor to bottom of the file and “p” for paste. Make sense. Efficient. But what truly makes a difference is that these atomics can be put together for something bigger, such as “dj” for some great music “delete this and next line”, “dG” for delete from this line to bottom of the file. Then throwing in some numbers to represent repetition such as “d2j” for “delete this and 2 next lines”. I feel it intuitive, and hopefully you find it the same way.

It’s really a smart design to give users these atomics as lego bricks, and have them combine them as they like. This leads to “1+1>2” and it reduces memorization cost drastically. Makes learning and using vim can actually be rewarding with like playing a puzzle game.

With minimum memorization of the keybinding, I can already achieve a lot that’s either impossible, or would have taken way greater efforts if using another editor. Many say the keymap of different modes of vim is daunting. I agree, but I never even try to remember all of them (even after using it for this many years). I’d rather take small steps learn the atomics only when I need so I don’t get overwhelmed. The design of vim also makes incremental learning so much fun because of the combinations I can make with the new atomic and the ones I already know.

When it gets to the point where I can comfortably keep my hand on the keyboard, and eliminating the need of lifting my hand for the mouse, doing some panning, scrolling and pinpointing, I realize how big a leap I made. What’s better is, at that stage, I didn’t even memorize all the single-keystroke atomics. And the “lego fun” even continues with more advanced concepts such as text object, and some good plugins, such as vim-commentary and vim-surround. When I throw in ‘ciw’ to remove a word with my cursor anywhere on the word, “oh boy I can do this all day (in cowboy accent)”.

Vim & VSCode

Nowadays, I rarely use vim the editor. A few scenarios include doing quick edits (on .bashrc or alike) on a server or sometimes writing git commit messages. Though, the vim keybinding is still an irreplaceable part of workflow. I have tried coding without vim keybinding. I was playing around Swift and SwiftUI for some Mac app. But it just feels back to the stone age when I lose my magic cursor movement dance with vim. (I’m aware of the existence of the vim mode on XCode but it still lacks many functionalities seemingly)

The editor/IDE I use mostly is VSCode, which has a great Vim emulation extension. VSCode does me good mostly because of the python plugin, decent remote SSH support and the great extension ecosystem that makes most of the things work with minimum efforts.

I think that’s it for today. Hope you enjoy your time reading this.