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:

• Extensibility
• Community
• Composability

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

• An Intro to Vim for People Who Use Visual Studio Code
• What are the benefits of learning Vim?
• Why should I use an IDE?
• Vim’s Big Idea
• Can someone explain to me why people use vi/vim?
• Why I use Vim
• Can someone explain to me why people use vi/vim?
• Why, oh WHY, do those #?@! nutheads use vi?
• Everyone Who Tried to Convince Me to use Vim was Wrong
• Your problem with Vim is that you don't grok vi
• Coming Home to Vim
• Shell from vi
• @learnvim

Comments

[Waylon Walker]

I've tried to switch to vim several times, but windows terminals are so terrible. The best way I have found to use vim is to open VSCode, set the terminal full screen toggle action bar and sidebar off and you have a decent terminal experience 😢

I mostly use VSCode, but the performance and extensibility of vim is wicked. That said any editor needs to have vim bindings.

[Jonathan Siddle]

Thanks for this, this is a really great article and I love it when references are included!

I tried to use Vim as my main editor but couldn't find a good flow with Flutter. I mostly use VS Code with the Vim extension, I am always striving for ways to become more keyboard driven and improve my Vim knowledge.

[Igor Irianto]

Yup. Many IDEs' Vim extensions are great. They are not perfect, but for everyday purposes, plugins are more than enough to help develop Vim muscle!

I personally never developed with Flutter, so I can't help much. If you ever make the jump to use vim/neovim directly (not through IDE extensions), I think something like github.com/iamcco/coc-flutter might be a good place to start. Plus github.com/sheerun/vim-polyglot has dart support (I use vim-polyglot for all my language needs).

Best of luck!

[Filipe Brandenburger]

Excellent article and you make great points! Your pros and cons are really balanced, which I find really refreshing on an article about Vim!

And so awesome that you mentioned the community aspect! Thank you so much for calling out the Vi and Vim Stack Exchange in particular. It's a great forum for all those interested in Vim, whether they're beginners or advanced users. It's very welcoming and you'll find many maintainers and authors of Vim and of Vim plug-ins hanging out there. (Disclaimer: I'm one of the three moderators.)

[hidden_dude]

I'm heavily influenced by the book "Writing Solid Code" by Steve MacGuire.

In the book he argues that developers shouldn't run their code, they should debug it in a graphical debugger (even if there's no problem). Its a great way to inspect the code as it executes.

Thats why having an IDE with no integrated debugger is a bit of a show stopper for me.

[Thomas H Jones II]

As someone whose first real editor was vi on SunOS 4.x, it's a hard habit to try to move on from. Plus, it's (well, vimis) still being actively developed/exteneded, so, if I want or need anything beyond the base functionality, it's easy enough to bolt on.

[Saurabh Sharma]

I usually don't code in vim, but when I do, I can't code in static typed languages without autocomplete, they are too verbose to write everything by hand. I use coc.nvim Intellisense engine for Vim8 & Neovim, full language server protocol support as VSCode.

[Igor Irianto]

I use that too. It's been great. I have been working on large codebase and in my experience, coc.nvim doesn't work very well (I have a very large controller, and it lags pretty bad).

On medium to small codebase like microapps, it works great!

Recently I tried turning coc.nvim off to see how I would do without it and just use Vim's native autocompletion, so far it's been great! (:h ins-completion for more info).

[Saurabh Sharma]

even in small project is makes vim noticeably slower, but I can bear that for the benefit of intellisense.

[Tama McGlinn]

I love this article; you hit the nail on the head with composability.

However, I'm surprised you didn't know how to debug using vim; it doesn't just have a debugger, it has one of the best in any IDE, because you keep all the other features enabling you to quickly move around the code, and allows you to define your own keybindings. Also, unlike most IDE's, it supports all programming languages.

I used to use idanarye/vim-vebugger, but switched to puremourning/vimspector because it had more features. I can confirm it works out-of-the-box for Ada and C++.

[Javier Salcedo]

Learning Vim was really a big boost in productivity (after surviving the dreaded learning curve).
I personally use mainly the Vim extension of VSCode. A match made in heaven ❤️
I can do almost anything that I can do with regular Vim, but with more IDE-like features and better highlighting.
Sometimes it can feel a bit more sluggish though.

[Igor Irianto]

I agree. Once you get into the habit of thinking in Vim, it's hard to let go!
It's pretty cool when you realize that there is practically at least a Vim extension in every major IDE/editors (VSCode, IntelliJ, Emacs).

[Bogdan C.]

Honestly, I understand that many people use Vim (even some of my colleagues do this, although in our standard development process we have some clear guidelines to use Eclipse / VS Code), but I cannot get used with it. I'm trying to learn it and like it, but after some sporadic trials, I almost gave up. Mind you that I only tried to use it for fun, not at work, where definitely wouldn't increase my productivity, or might even help me to destroy the quality :D

I simply cannot see its "simplicity", unless one really hates the mouse (which I find it extremely powerful in combination with a keyboard) and only prefers to use shortcuts, like they do in the "hacker movies".

So, for my day to day work, where we have projects with tens of thousands of files spread over modules and submodules, I really cannot see the use of this tool. It's cool, it brings me back some '80s memories, but other than that...it is simply not even coming close to a modern IDE such as Eclipse or VS Code, designed pretty well for working on large projects.

Even when it comes to simply opening a file and modifying it, VS Code (or Notepad++) does the job neatly and I don't need to memorize a whole book of shortcuts.

So, as others have said, I'm trying to learn VIM just for fun and for the sake of the argument, but until now I haven't managed to master it and I have to keep the cheat sheet open to see all those combinations of letters :)

I've had this discussion with some of my colleagues who also keep insisting on using directly the terminal for some GIT commands, although we have very powerful GUIs for this purpose, which makes it faster, safer and easier to use...but, that's another topic :D

[JustinKaffenberger]

I prefer full IDE's in the circumstance where I need to do large scale refactorings in a code base.

[Igor Irianto]

As a Vim user, I do not disagree. There is truth in that.