State of Vim 2022

As I had mentioned in my post about the impending death of Atom, I typically use VS Code for most of my professional coding work while I use Vim for most of my personal coding. This got me thinking a little more about why exactly that is; why do I use VS Code professionally but Vim personally?

The Vim Side

On the Vim side of things, I enjoy it because, for the most part, it’s simple and lean. However, the plugin ecosystem means that I can typically add plugins for most of the functionality I may need, from supporting syntax that isn’t available out of the box to tweaking the interface. Vim is also ubiguitous, as it (or at least Vi) is installed on pretty much everything by default. Whether I’m working on something on my local machine or if I’m exec’d into a container, I can have more or less the same editing experience. Even with just personal projects, Vim is something I can use pretty much everywhere. My laptop running Fedora has it, and the VPS I run also has it if I want to write some code from my iPad — which is a post in itself for another time.

When working from my laptop, it’s also nice to not have to swap between a terminal and an editor; I’m just swapping between tabs in the same application. If I need to look at 2, 3, or even 4 files at the same time, can quickly fire up tmux to accomplish that.

Of course, the biggest benefit of all is just the speed of editing that Vim offers. While I admit that the learning curve is a bit steep compared to something like VS Code or nano — I know a frightening number of sysadmins who still use nano every time they SSH into a machine they manage — the payoff is well worth it. Having used Vim in some capacity for over a decade, my ability to edit with it is much faster than with anything else. Similarly, this also means that my speed isn’t beholden to whether or not the keyboard I happen to be using has Home, End, Page Up, and Page Down keys, which is the next best thing I’ve found to using Vim’s modal editor.

The VS Code Side

On the VS Code side, the primary driver for me is just the fact that it’s simple for me to open an entire folder and quickly swap between all of the files contained in that particular project. While less of an issue in most of my smaller projects, I’ve recently been working on significantly more files at a time (and jumping between them when I fix my extremely broken code) than usual.

Similarly, the IntelliSense that VS Code offers for a variety of languages, especially Python, is pretty nice. I’m working with Python as my primary language at the moment where previously I’ve used mainly PowerShell and Groovy, so having hints for parameters, methods, etc. is quite helpful.

As I mentioned in my other post, VS Code does have a Vim extension for adding Vim’s modal editor, but for some reason I just didn’t like it as much. While it was still super useful for things like using keyboards that don’t feature a full compliment of keys, I ended up feeling like I still wasn’t quite as efficient since I was so regularly reaching for the mouse for other things. I’ll be the first to admit this might just be mental on my part. 🙃

Swapping to Vim

With all of this in mind, I decided that I wanted to give Vim another shot as my “one” editor. While IntelliSense is nice, I think there’s something to be said for forcing me to spend a little bit of mental effort remembering some aspects of Python myself rather than using IntelliSense; I think it could do me some good. For things like function and variable names, the auto-complete for pretty much any editor, including Vim, could help me with that.

This just left working with multiple files, something I had struggled with previously. I knew Vim had tabs, but I was never particularly well versed in them… obviously. So I decided to do a little digging and spend some time practicing with a few of my current projects. It didn’t take me long to realize I could easily open a new tab with the following command within Vim:

:tabnew {file_path}

Swapping between tabs at first was a little more cumbersome as I used:

:tabn

… for the next tab and…

:tabp

… for the previous tab. That’s a bit more typing than I’d like. However, I learned I can also do:

gt

… for the next tab while in Normal mode and…

gT

… for the previous tab. Much better! However, this was still a bit cumbersome when I found myself with 3+ tabs open as I didn’t want to have to hit those keys multiple times. Vim offers the ability to type:

#gt

… from Normal mode where # is the number of the tab you want, starting with 1. This was much faster because I could jump to the exact tab that I needed. However, it was still a little clunky because when venturing into 5+ tabs it wasn’t always apparent which number I needed and having to quickly count felt silly. After some additional searching, I found this slick little function that I added to my .vimrc file. It’ll display the number on the tab so that I don’t even have to think about which one I need; I can just quickly hit the number followed by the g and t keys.

Extensions

I feel like I’d be remiss if I didn’t also mention some of the Vim extension that have been pretty critical to my workflow. Naturally, several of these are a result of my specific job functions whereas others are probably going to be universally useful to anyone leveraging Vim.

1. Pathogen: This gets the first nod from me since it’s the plugin manager I use to add everything else to Vim! There are a handful of plugin managers available, but I’ve always found Pathogen to be extremely simple and reliable, so I’ve not ventured into trying out any others.
2. Airline: A terrific plugin for showing status information about the currently open file. While it’s handy on its own, it’s really slick with…
3. Fugitive: Fugitive intergrates with Airline to display Git information about the currently open file. What branch I’m on, if there are changes to be committed, etc. is all available within the Airline bar thanks to Fugitive.
4. OneDark: This is my preferred theme at the moment, coming from the default theme of the soon to be departed Atom. I really like the way it looks, though I’ve spent the largest portion of my time with Vim using the terrific Dracula theme.
5. Dockerfile: As someone without a ton of Docker experience, this plugin’s syntax highlighting is terrific for letting me know about syntax errors before I actually try to run a build.
6. Groovy: I don’t write nearly as much Groovy these days as I used to, but when it comes up, I like having some syntax highlighting available. While it’s been archived, it still does a solid job on the current Groovy release (4.0.3 at the time of this writing.)
7. Markdown: Vim’s default Markdown syntax highlighting is decent, but there are some instances where it’ll get a bit confused about things like quotes. Along with fixing those issues, this plugin will also allow for sections of a Markdown file to be collapsable, which is surprisingly handy when working with longer documents.
8. Terraform: Similar to Docker, I’m not exactly savvy when it comes to Terraform, so having a plugin to help me with syntax highlighting that’ll tell me I’ve done something wrong prior to actually executing anything is very helpful.
9. WakaTime: This one is mostly for fun just to track how much time I spend writing code, but it’s also useful for instances where I need to track how much time I spent on a particular project or working for a particular client at my job.

Those are the plugins that tend to fall into my “must-have” category. While I spend most of my time working with Python, I’ve found the default Python syntax highlighting to be more than adequate, so I’ve not tried to look for anything more elaborate. I’ll try to remember to update this post in the future if I run across anything additional!