Visual Studio Code? More like Vim Studio Code
So I recently started using Vim last week. Well, not exactly Vim, but it’s close enough. The Vim extension for VS Code is the perfect way to combine the power of Microsoft’s VS Code and efficient Vim commands. If you don’t know what Vim is, here is a quick rundown.
In 1976, vi was created. It is a text editor created for the Unix operating system that allows the user to enjoy the full “visual” screen mode of modern terminals (I’m beginning to notice a running pattern of the word “visual” or honestly anything that starts with ‘v’ with these text editors…). In 1991, Vim, or Vi IMproved, was released to the public. Vim’s main selling point is that it focuses entirely on using keyboard inputs and doesn’t require any usage of the mouse. To move your cursor around, you use h, j, k,, and l, for left, down, up, and right, respectively. Notice how all of these are home row keys (and they are lowercase on purpose). To enter insert mode, you press i. Now typing hjkl will actually add that to where your cursor is like in any regular text editor. To exit insert mode and return to “readonly,” you hit the ESC key, although I prefer to use CTRL + C(and no, that doesn’t do “copy” in Vim). If you want a fully list of all the commands in Vim, you can find resources like this Vim Cheat Sheet, although I wouldn’t be surprised if not everything is listed on there. A common occurrence with Vim is that even experts learn new commands that the text editor can perform while demoing it to someone else.
If that cheat sheet is too hard to digest (and you would also like a guide on how to get started with Vim in VS Code) I recommend giving my Vim Guide on GitHub a read. It’s quite concise and gets you set up with the basic commands that Vim has to offer. I might be getting a little ahead of myself, however, since I haven’t really explained the reasoning for using Vim. Why use an outdated text editor to write code? Why use it to edit any text for that matter?
Philosophy of Vim
I hate to break it to you, but I switched editors in the middle of this blog post. Apologies for my Machiavellian behavior. Everything prior to the “Philosophy of Vim” section was created “natively,” in the Medium rich text editor. As soon as I started to type up the next section, I realized I was missing out on an opportunity to use Vim. So, I created a dummy Markdown file, opened it in VS Code, and wrote some Markdown “code” (Any senior HTML developers here?) including headers and a link. I opened a preview of the tab with a VS Code extension, copied that, and pasted it back into the Medium text editor. To my surprise, it looked like it formatted correctly. I have yet to test it out with images, but I’m probably going to find out during the remainder of my writing if it works without issue. Back to the philosophy of Vim.
To start, I’d like to point out that “Philosophy of Vim” might be a bit misleading. There are plenty of other text editors that come to mind that have very similar functionality to Vim. Emacs comes to mind. And don’t forget that I’m not using Vim itself; I’m using an extension of VS Code that simulates Vim commands. What I’m trying to say is that I am not a proponent of Vim elitism. I am, however, a advocate of keyboard elitism, a principle that I am far from fully embodying. Keyboard elitism is what really backs the “Philosophy of Vim.”
The idea is that every time you move your hands away from your keyboard (or even more extreme, every time you move your hands away from the home row), you are being inefficient; you are wasting time. Why would you move your hands away from your keyboard? Well the first scenario that comes to mind is reaching for your mouse (which I’ve honestly done a few times already while writing this). The mouse is so useful! You can click on files, move your cursor to a different location, and even switch windows with it! That comment was partially sarcastic. I sincerely hope that you’ve been using <ALT> + <TAB> or the equivalent for your OS to switch windows. But I do sincerely mean that the mouse is useful. The problem with the mouse is that it's not part of the keyboard. On top of losing time from moving your hand back and forth, you can actually get seriously injured from flicking your wrist too quickly between the two peripherals (I know this isn't CSGO, but hey, the risk is still there). You might laugh, but I'm not talking about a broken wrist here, as that is extremely unlikely from using a keyboard and mouse. I'm talking about a slow, dull pain that gnaws away at your joints over time. It doesn't have to be a muscle being pulled, or a bone being broken. It can start off as simple joint pain, and eventually elevate to limited joint flexibility or even arthritis. Sure, this one is also unlikely, but it's far more plausible than the former outcome.
So we’ve established the potentially devastating perils associated with mouse + keyboard usage, so how do we circumvent this problem? As you’ve already guessed, it’s to limit the usage of the mouse. This is what Vim accomplishes. With Vim, you no longer need to stop typing, lift your hand, move it to the mouse, adjust your mouse pointer to the desired location, click, life your hand, and move it back to the keyboard. All you have to do is type in the proper command. Say I’m on line 21, and I need to jump to line 69. All I have to type is 69gg and I'm there. Of course, that isn't the only way to get there. I can navigate my cursor to a word that I already know is in line 69. Let's say the word is "spaghetti." I just type /spagh and I'm probably already there. The / command is like a search function, similar to <CTRL> + F in your browser window or VS Code itself. I can even jump around with command combinations like 10j or 20k to jump down 10 lines or jump up 20 lines, respectively. There are an infinite number of ways to navigate around in Vim.
Combining Forces: Vim and VS Code
Using the Vim extension for VS Code has been a great experience for the past week. The Vim commands do what VS Code’s text editor can’t do easily without mouse usage. The VS Code extensions do so much of what Vim can’t customize. The VS Code file explorer and terminal make it so much easier to find files and run projects. I’m not saying that this is the ultimate coding/text-editing solution. If you’re a little insane, you can make Vim like VS Code, rather than the other way around. But let’s not get sidetracked here. What’s so great about Vim commands being integrated into VS Code?
First of all, it encourages you to use the keyboard even beyond the Vim commands. There are VS Code shortcuts that I either vaguely knew about, or had no idea of until I started learning Vim. By forcing myself to only use the keyboard for navigating around a file and editing it, I decided it would make sense to (mostly) limit myself to the keyboard for functions outside of the text itself. For example, I always used my mouse to open files, but now I try to use <CTRL> + P, which allows me to search files by name and open them without lifting my hand away from my keyboard. I also started using the VS Code command palette a lot more (<CTRL> + <SHIFT> + P), which has tons of useful options, the most notable of which is opening the settings.json file. Whether I need to change my editor's font family, disable font ligatures, or update some obscure bracket setting, it's just a few key presses away.
As I alluded to earlier, VS Code extensions can result in some really useful synergies with Vim. There is the bracket pair colorizer extension, which makes bracket pairings even clearer alongside Vim’s % command, which makes your cursor jump back and forth between two paired brackets. I would definitely advise using VS Code's built-in version of this extension now, however: Native bracket pair colorization
At the same time, Vim mingling with VS Code can lead to some pretty funky interactions, like in the case of code snippet extensions. While creating a full stack chat application in React, I commonly used the rafce snippet from the ES7+ React/Redux/React-Native snippets extension. However, this snippet in particular was predicated upon the multi cursor functionality of VS Code, which Vim is usually a stranger to. The first time I encountered this, I wasn't sure what to do. The extension had enabled me to quickly generate some boilerplate code for a React component, but at the same time, it placed three cursors on my screen, which I didn't need. After doing CTRL + C like I usually do to exit insert mode, I was surprised to see that there was still three cursors, all in readonly mode! My next instinct was to keep hitting j until the three cursors lined up at the same exact spot on the first line (I'm now assuming that gg would have been even faster). After they did align on the same spot, I wondered if there were actually three cursors on the same spot, or if they had somehow coalesced into one. I entered insert mode with i and started by typing one character. To my relief, only one character was typed, and not three, instantaneously. It just goes to show that when two vastly different text editors meet, there are certain interactions that won't turn out too pretty.
Speaking of pretty, I haven’t found the courage to commit to the Prettier code formatter extension. The first time I tried it was before I started using Vim with VS Code, and I still didn’t enjoy it (and before you yell at me, yes I did configure it to reformat my code every time I saved a file). I found it annoying how the effort that I went to format my code in the way that I found readable (which isn’t anything unreasonable) was being actively destroyed every time I saved. Aside from that annoyance of principle, the formatting that Prettier did to my code was a bit harder to read than what I was used to. So I ended up uninstalling it. When I started to use Vim with VS Code a few weeks after that initial experience, I decided to give Prettier another try. To be concise, the second experience was worse than the first, and I uninstalled it again.
Final Thoughts
I just tried pasting the preview of my Markdown file to Medium, and I have to say, it went pretty well. The one thing that it can’t cover (that I needed for this post) is the ability to add captions to images, or at least, I think that’s the case. I haven’t done much experimenting with that just yet. To get images into the Markdown, I just used some basic HTML <img> tags and included the image address under the src attribute. Though I didn't need it for this post, I'll also have to figure out if I can include GitHub Gists into Markdown. Of course, if it's not possible, I'll just paste in the link like I usually do. I'm getting sidetracked again! What can I conclude about combining Vim with VS Code?
Above all else, the Vim extension for VS Code has been a great way for me to learn something new — not Vim, but just something new in general. It was also something out of my comfort zone, as, like most people who use computers, I’ve been conditioned to using the mouse and keyboard (and the trackpad when I unfortunately don’t have access to a mouse). If you want to learn something new that implements some “old school” technology while also improving your efficiency and reducing risk of joint injuries, give it a try!
Fun fact: Changing the height attribute of an <img> tag in Markdown changes it for the rendered preview, but not when that preview is pasted into a rich text editor like that on Medium!
