irian.to

Why I use Vim

June 9, 2020

Why I use Vim

My first experience with Vim was when I accidentally entered it and could not get out. I had to google how to exit vim to escape. I asked, "why would anyone ever use this awful editor?"

Fast forward 4 years, this awful editor is now my primary editor. I've tried editors like Notepad++, Atom, Vim, Sublime, Brackets, Vim again, Emacs, IntelliJ, Spacemacs, VSCode, and finally Vim again. In the end, I always came back to Vim.

In this article, I want to share 3 core features Vim has that made me come back to Vim (plus a few more). Then, I will discuss Vim's limitations.

I think a great editor needs to have these three features:

I use Vim because it has all the three features above . Let me explain each of them.

Extensibility

If you've used VSCode, Atom, or Sublime, then you know being able to add and remove plugins easily is an indispensable feature.

Do you want git helper? Well, VSCode has Git Lens. Within a minute, you have git lens running. Do you need to rainbow your brackets? There is Rainbow Brackets. You want a different theme? There are probably hundreds to choose from.

All great modern text editors/ IDEs must be extensible. I can't think any successful text editor without this feature.

In early 2010, Vim didn't have many plugins available. But it is 2020 and there are many powerful plugins available now. Do you want a git helper? Vim has vim-fugitive. Do you need to rainbow your brackets? There is rainbow. You want a different theme? There are hundreds of theme on vimcolors.

In addition, Vim has some plugins that can make it to behave like an IDE: fzf.vim for fuzzy search, coc.nvim for Intellisense engine, ale for linting, gutentags for jumping to definitions, and more.

There are several plugin managers (vim-plug, vundle, dein.vim, etc.) to choose from today. Granted, it's not as convenient as adding plugin via VSCode marketplace where you can just type in any plugin you want and install it on-premise, but I can add and remove a Vim plugin in less than a minute, which is for me is good enough. It's not a dealbreaker.

Community

Community is an important feature in open source technology. A strong community guarantees continuous development and bug fixes as long as there are sufficient contributing developers.

It also implies more community plugins, more tutorials, and more human supports.

Vim has a great community. It has a reddit page, stackexchange, many dedicated twitter accounts, and more.

You will observe all popular editors today have a sufficiently large users. I'll bet there are many here using VSCode, Atom, and even Emacs. Without a community, even the greatest editor will quickly disappear to obscurity.

Composability

In addition to having extensibility and community, Vim has composability, a feature I think is missing from many non-modal editors.

Compo..what?

Composability means having a set of general commands that can be combined to perform more complex commands. Just like in programming where you can create complex abstractions from simpler abstractions, in Vim, you can execute complex commands from simpler commands.

Vim has motions for moving and operators for editing (there are also text objects, but I won't cover them here).

Let's start with motions. The motions e, $, }, G mean "end of word", "end of line", "end of paragraph", and "end of file" (for a list of Vim motions, check out :h motion.txt). Each motion is simple and does only one thing: "go to X".

Let's talk about operators. d is a "delete" operator (for a list of operators, check out :h operator). In Vim, you can use operators with operator + {motion}. It needs a motion as argument.

More examples of combining d operator with motions:

  • If you give d an e argument, de tells vim to "delete to the end of next word".
  • What if you want to delete to the end of the line? d$.
  • What if you want to delete to the end of the paragraph? d}.
  • What if you want to delete to the end of the file? dG.

Search (/) is also a motion, so it works with operators. To delete from your location to the next instance of "foo", you can do d/foo (d delete + /foo search for next instance of "foo").

Vim works seamlessly with external commands. Vim has a filter operator to apply external program: !. For example, if you want to tabularize this messy text below, you can't really do this easily with Vim's internal commands, but you can do this easily with column shell command.

Id|Name|Awesomeness
01|Iggy|Very
02|Johnny|Ok
03|Mary|Ok

With your cursor on top left corner (on "Id"), apply filter-operator (!) from current location to the end of paragraph (}) using column -t -s "|" command as filter.

Running !}column -t -s "|" gives you this tabular data:

Id  Name    Awesomeness
01  Iggy    Very
02  Johnny  Ok
03  Mary    Ok

I can also chain column with awk to extract only the rows with "Ok":

!}column -t -s "|" | awk 'NR > 1 && /Ok/ {print $0}'

You'll get a filtered and tidied data:

02  Johnny  Ok
03  Mary    Ok

This is the power of Vim's compositional nature. It is consistent and intuitive. You are not in some isolated environment where you can't use shell commands. You have free access to use any shell commands as filters to your text. The more you know your operators, motions, and shell commands, your abilities to compose actions are multiplied.

Let me elaborate. Suppose you only know four motions e, $, }, G and a delete (d) operator. You can do 8 things: move (4) and 4 different deletes (de, d$, d}, dG). Then you learn a new uppercase (gU) operator. You have added not just one more thing into your Vim tool belt, but four: gUe, gU$, gU}, gUG. Now you have 12 tools in your Vim tool belt. Each piece of knowledge is a multiplier to your current compositional tool belt. If you know 10 motions (easy to do) and 5 operators (another easy target to reach), now you have 60 tools (5 * 10 + 10). Vim's go-to motion (nG) gives you "n" motions, where n is how many lines you have in your file (example: to go to line 5, 5G). Vim's search motion (/) practically gives you near unlimited number motion because you can search for anything. External command operator (!) gives you as many filtering tools as the number of shell commands you know. With composability, everything you know can be used together to perform more complex operations. The more you know, the more powerful you become.

Vim's composability echoes Unix philosophy: do one thing well. A motion has one job: go to X. An operator has one job: do Y. By combining an operator with motions, you get YX: do Y on X.

More features

In addition to having great community, extendable, and composable, Vim is also:

  1. Lightweight and fast. It takes about 40ms for me to start it without plugins and 180ms to start it with plugins.
  2. Universal. Vi/ Vim is likely available inside any Unix machines.
  3. Favors touch typists. This is a personal preference, but moving my hand to reach a mouse interrupts my thinking flow. I can code mouse-free with Vim. This efficiency allows me to concentrate more on code, not the editor.
  4. Helpful help. :help is very extensive. There is even :h helphelp to help us to use help. So meta.
  5. Customizable. .vimrc or .vim is customizable. Vim has a robust plugins structure and even its own language (Vimscript) for customizing itself.

Vim limitations

Vim has several limitations, but the obvious one is its learning curve. This can be a huge deterrent for newcomers. It takes weeks to build Vim muscle memory. If you're a full-time programmer with looming deadlines, you probably will not and should not jump to Vim cold-turkey and have your productivity cut by 90%. Yehuda Katz (EmberJS) wrote an excellent article how he transitioned to Vim. If you're considering switching to Vim and worried about productivity loss, his article is insightful.

Second, some Vim plugins don't work well on large projects. I've noticed ctags would miss definitions and auto-completion would lag. I don't have this problem with VSCode or Intellij. Maybe it will be different in the future.

Third, Vim is not an IDE. It can be customized to look like one, but the more you try to make it to look like an IDE, the less it behaves like vim (fast and lightweight). If you need a full-fledged IDE features, use a real IDE.

Fourth, it has no debugger. VSCode makes debugging Javascript code almost fun. Vim does not have that feature. You can always debug client-side code from chrome devtools and backend code with node debugger. It's not a dealbreaker for me. Mankind has been debugging from terminal since the dawn of times. But frankly, I wish there is a functional debugger for Vim.

Fifth, it's not significantly faster than popular editors. At work I sometimes pair program. We usually use VSCode. I notice that my average editing speed when using VSCode is roughly the same when using Vim.

Conclusion: why I still use Vim

I think a good question to end this article is, "When will I stop using Vim as my primary editor?"

I still use Vim because of the three core features above. If somewhere in the future comes a text editor / IDE that has extensibility, community, and composability, in addition to being universal and lightweight and other helpful features that Vim doesn't have, I will consider switching. I haven't seen one yet, so I will still use Vim as my primary editor.

I believe a good editor should feel like a natural extension of your thought processes, if it doesn't, you probably are not using the right one. Try them all and find the one that fits your style.

At the end of the day, a text editor/ IDE is a tool to a programmer, like a hammer is a tool to a carpenter. A carpenter does not get paid based on how many tricks he can do with his hammer, but based on his woodwork quality. The hammer is also not a carpenter's only tool (he needs to use other tools too), but knowing how to use his main tool efficiently will help to make his job easier.

Find your own favorite tool and learn it well.

Thanks for reading.

Resources