How I Stopped Worrying and Loved Vim
Most likely, if you are reading this, you can’t grasp, why would someone ever use Vim as a primary code editor? And if someone really does use it, there must be a good reason. I was in your shoes once. When I found out that someone really preferred Vim as their code editor over an IDE, a lot of questions started bothering me.
Beginning
I knew about Vim’s existence since college, but I could not imagine that it could be something suitable for coding. I thought of Vim as a last resort — as a tool for minor changing text somewhere on a server via ssh. Nothing more.
Excitement
Things changed when I heard that one of my colleges used Vim for coding. It is important to clarify that the colleague was a very skillful developer with a more than ten years experience in production. I was curious about that and couldn’t imagine that Vim was suitable for coding. So I asked him why he was using Vim instead of Jetbrains IDE or VSCode. IDEs have so many useful tools and features.
I have the most useful of them on my Vim configuration. Also, most IDEs are so resource-intensive to provide all the features that I usually don’t use. When I use a code editor 8 hours every day, I want to be able to configure every single part of it and then keep it. — Developer
I thought about his words and tried to configure my first Vim that evening. The feeling of coding without a mouse in a fully customizable environment was something new and attractive.
Disappointment
Unfortunately, I used the very first Typescript Vim config that I was lucky to find on the Internet instead of configuring one on my own.
Of course, it was not the best one. I didn’t know how to work with that configuration. It was slow and looked unpleasant — not how I wanted it to look. That is how my typical day was like: I started coding using Vim, my productivity dropped, I got disappointed, I returned to VSCode. Repeat. My overall efficiency dropped. I had to use third-party tools to replace some of the IDE’s features.
After a week of constant tries, I gave up and returned to VSCode.
Second Chance
“He remembered what the old man had said” — The Alchemist
A month later, I remembered that my colleague had said earlier that Vim was the tool you could configure as you liked. So, I decided to give it a second chance and make my own Vim configuration this time.
I started coding a simple app, and every time, I felt that I needed something. And I got that “something” after configuring or adding plugins.
I strongly recommend you to do the same before looking up for someone else’s configuration.
After I had configured Vim as I liked it, I started working in it permanently. It was hard. There were things like multi cursor, or integrated git that I missed. But Vim always ended up having a way to do those things.
If you find all these problems that bother you while coding in Vim and then solve them, you will love it.
Things that irritated me
Here, I will give you a short description of things that were bothering me at the beginning. And the solutions I have found.
File tree
It sounds silly, but you don’t need a file tree most of the time. It is useful for manipulating files of a project, creation, removing, etc.
Using an IDE, I repeatedly found myself jumping between files thoughtlessly. When I was accustomed to a permanent switching between files, I was losing my focus. I stopped thinking about the next move I have to do and started clicking on tabs.
Programming is about thinking not writing. Think, then write and not vice versa.
Vim has a built-in tool for viewing and manipulating files. It is called explorer. Or you can use NERDtree, in case you want some more features. But most of the time, I prefer navigating using file search (I use ctrlp plugin), jumping using go-to-definition/go-to-reference features, or jumplist Ctrl-O/Ctrl-I.
Buffers
Vim has a thing that is called buffers. They are files that you opened, and that were loaded into your Vim memory. You can use them to navigate as well. They are like tabs in VSCode or an IDE. To work with them efficiently you can use vim-buffergator plugin or configure key mappings.
Code Completion
That is one of the main reasons people use IDEs. But for most popular programming languages, at this time, language servers exist. In a word, LSP (Language Server Protocol) is a tool that can provide code analysis. And it is editor agnostic. You only need a client to work with LSP. In the Vim world, you can use coc.nvim. It is an Intellisense engine that can provide Vim with all the code analysis that VSCode can. You can install a plugin for the language you use and coc.nvim will do the rest.
Code completion looks like this in my case:
Searching
Vim has a built-in tool for searching, but I prefer using fzf.vim. It is a wrapper for the fzf search tool. I use it with ripgrep search tool. This thing is written in rust and it is really fast.
Git
There is a really good tool for working with git from Vim. It is called vim-fugitive. This tool is a wrapper for git commands, and it can provide all you need to work with git.
But, if you are a casual user, like me, check out an awesome tool called lazygit. It is a terminal-UI tool for git manipulations. And there is a plugin to integrate lazygit into Vim — lazygit.vim
This tool will let you work with git and make things like cherry-picking, merging, etc. in the usual way.
Summary
If you write code on a daily basis, I definitely recommend you trying Vim. Start with vimtutor, and then try coding.
It’s hard to start, but if you go through it, you will love Vim.
Some articles that helped me:
P.S. I use Neovim.
