VSCode with Vim

Why using VSCode w/Vim is great

I have recently started using VSCode again, and it might be incredible enough to become my full time editor. Let’s see why that might be the case.

Isn’t Terminal Vim enough?

I have been using terminal Vim exclusively over the last several months and really enjoying it. I can get to the editor quickly by typing vi . in a repo. If I am in Vim, I can press ctrl + z to get back to the terminal quickly to make git commits. That suspends Vim so that I can resume my Vim session quickly by typing fg <cr>. It is for these reasons that getting into Vim and out of Vim (for some, this sounds like a nightmare) quickly.

As much as I like terminal Vim, it is not without shortcomings. When I open large files in Vim and I try to scroll through the file, there is considerable screen lag. Also, if I want to do a global search in a repo, I have been choosing the path of least resistance and using Ack in the terminal to do a global search.

Although it is good enough for me, there are things that my VimScript skills and Vim customization foo just seem to leave out enough great things for me to not be totally satisfied. I love that I have created my editor with a base install of Vim and that it works in my terminal without issue, but there were some things from IDEs that I just never got to work in Vim. And as comfortable as MacVim is for projects that get weeks of work without shutting it down, it was also lacking some of these things.

There is oni, a project to bring modern IDE features to a standalone Vim based editor. But it has been < version 1.0 for a long time (nothing against this, as we all know that writing open source software is not easy) and, at least when I tried it out, left me without desire for it to become my full time editor.

There is the Vim plugin for IDEs like any of the JetBrains IDEs contain. I know that JetBrains makes excellent tools that are super powerful, but for some reason, they never grabbed me and filled me with desire to use them for very long as my main editor. One of the things I love about NerdTree, the Vim plugin for file exploration, is the ability to use the direction controls in Vim h j k l to navigate in and out of files and through the list. You can also search for files with the normal Vim bindings, /<searchterm>, or naviage to the top or bottom of the file tree as well with gg or G respectively. I have never found that to be the case with the Vim IDE plugins.

How good is VSCode with Vim

And then I tried VSCode again, after not having used it for a year or so. I was surprised that the file explorer was able to be navigated with my Vim bindings without any issues at all. It was a little strange that <cr> did not open a file, but went into renaming mode, but that was easy to change. I was able to have just my open buffers showing in tabs at the top of the editor, and the statusbar at the bottom of the editor. I was able to toggle the file explorer quickly with keybindings command + b and open the terminal window to make git commits quickly ctrl + (backtick) or command + j if the terminal was the last thing to be used in the panel.

The breadcrumbs feature shows me exactly where I am in the file and in the project at a quick glance. It is super helpful even showing the method or section that you are current editing.

Searching for a file is super easy with cmd + p. It makes file switching a breeze. Using cmd + f to find a variable or string quickly isn’t replaced by using Vim’s /<searchterm>, but is an additional way to search, search and replace that takes advantage of quick search that IDEs do so well, and VSCode is no exception to this quick search feature.

Using gd to go to a definition is fantastic. When I was using terminal Vim, I could never get this to work across files. If I had an import in a file and I wanted to go the the definition in another file, it would take me to the place I imported, but would stop there. Out of the box, VSCode will go the definition directly in another file, even going into default Python files and definitions found in node_modules. That is very impressive.

When you have an error squiggle under some of your text, typing gh will bring up the tooltip describing the error.

What is better in VSCode

Vim for VSCode is pretty fantastic. It even gives some of the most popular plugins that I would miss with other IDEs implementation of Vim as just a set of keybindings rather than a way to interact with an editor. EasyMotion, Vim-surround, Vim-commentary are three plugins that make the transition to VSCode from Vim a lot easier and they are built in. That is fantastic.

Final Thoughts

I have spent about the last month using VSCode as my primary editor. I have been keeping the mindset that I try to keep most things as close to default as possible, but some settings changes were mandatory. Luckily, the Sync Settings plugin makes keeping my setting synchronized across my machines a breeze. These setting sync to a gist in my Github account, so I don’t even need to remember to commit changes to my editor. It happens automatically when I make a change to my settings. That is slick and allows me to save time to actually write code. In the end, that I why I like Vim—I like to save time and interact with my editor in thoughts—and that is why I think VSCode’s implementation of Vim is even better than stock Vim, other attempts at making IDEs based on Vim, or other well known editor’s implementation of Vim. I still feel like I am using Vim when I use VScode, just with superpowers. Unless Vim takes a light-year leap forward in the future, VSCode is my favorite way to use Vim to write. I am not looking back at the way things were, but forward to how good VSCode with Vim can actually get. I am impressed and satisfied with the implementation of Vim into VSCode. I have found my new favorite way to code. Thank you, Microsoft!