Breaking Through The Vim Learning Curve

Written by Stride | Published 2018/05/09
Tech Story Tags: vim | computer-science | code | markdown | linux

TLDRvia the TL;DR App

I tried to learn Vim, believe me, many times. As many times as I tried, I failed. That is until two weeks ago, when something inside my ancient and slightly decrepit mind clicked, and I started to see the way. I began to, as some might say, Vim. It was very exciting (and yes, I’m allowed to use it as a verb).

I don’t have to tell you why you might like to use Vim and I also don’t need to tell you that you need a list of any of the excellent resources out there to learn it. There are as many different approaches as there are key bindings, but I hope to share with you my approach, how it was helpful, and how it might help you.

The Past And Why It Didn’t Work

Previously, I ran through Vim Tutor, watched some of the excellent talks from Ben Orenstein and Chris Hunt, and played some of the way through Vim Adventures, but the experience was esoteric and academic.

On top of that, I made the mistake of installing Thoughtbot’s dotfiles repo which gave me A LOT of options and plugins, adding to the confusion. Not only was I trying to learn Vim, I was also trying to learn twenty plugins simultaneously. They had an amazing selection of tools, but as a starting point, it was too much for me to handle.

Furthermore, every time I tried applying some of these fledgling skills to a code base I cared about, the frustration of knowing the code I wanted to write and being unable to manipulate the editor the way I wanted was so maddening, I gave up and went back to Sublime (which I still love).

How It Finally Happened

First, I found a great tool, Vim Genius, and started playing with it. Despite occasionally getting out of sync, it’s a flash-card style semi-game that helped mebuild some muscle memory. Going through Vim Adventures was supposed to do the same thing, but I put on some good techno music, played Vim Genius, and felt cool when I made progress! It was fun to zone out to and repeat until I got it.

Second, I found a great .vimrc. As I mentioned, Thoughtbot was jammed full of plugins, extensions, and remappings. Pairing things down was really helpful and made the whole endeavour more approachable. Luckily, two awesome people at Stride, Cody and Claire, had a good .vimrc that was forked off of the Pivotal .vimrc and could serve as a starting point as well as a curated suggestion of what plugins to start with. You can get it from our repo.

There’s also a nice Readme that will help you get all the plugins installed. After that, you should be good to go. I did not further installation nor customization of my vim setup, which is nice.

Third, and perhaps the most crucial step, I gave myself missions with specific requirements. I picked tasks that were separate from code I wanted to work in, navigate, change quickly, and separate from code that had time constraints or expectations. Giving myself small things made it achievable and motivated me to see what I could get up to. By removing it from the constraints of performance made it easy to go slow, make mistakes, and look up a hundred different things every few minutes.

Reading Code

I love reading code. Beyond learning something about code, design, and different technologies, it also makes a great task for using the basic Vim commands for navigating. Beyond the basic up/down/left/right, it’s great to use G, gg to jump to the end and beginning of the file, respectively, $ for the end of lines, and { for moving up and down paragraphs in a Readme.

It’s also a great way to start jumping around between files using nerdtree. Simply opening and closing the tree with | and || gives an easy way to jump more globally within a project.

This reinforces the muscle memory of the basic commands from Vim Genius but also helps you feel confident as you start looking for something you’ll be able to find it and not get lost!

Writing Markdown

Writing code is complicated. Trying to write code in Vim while not knowing Vim is even more complicated. It was one of the key points that contributed to my repeated failures to learn. I decided to make my life easier and focus on writing some documents in Markdown. That was more manageable and something I could be successful with.

First order of business was Markdown Preview. I loved being able to see how nice my rendered markdown looked. But so much how? I found vim-instant-markdown which was nice and made me feel fancy that I could install a Vim plugin. The instructions on the Readme worked and, word to the wise, if you’re using one of the .vimrc’s mentioned above, you will already have filetype plugin on.

But spelling! :set spell. That was nice! And z= over one of my highlighted misspellings gave me the suggested correction. Thanks Vim! And when I was done with misspellings? :set nospell. Ahhhh.

I liked line wrapping at 80 characters. Simple enough: set textwidth=80 and if I wanted to reformat, enter visual mode, v, use j or k to select up or down and then gq to reformat. Nice!

o and O and a and A and i became reflexive for inserting.

Also, zR to unfold your markdown file if it gets folded. The R unfolds all folds, which is what I liked to do when things were folded.

And finally, my favorite trick, shift-j to join the line below to your current line!

This was when I really started having fun, in part because I like writing things, but also because I could feel the vimness happening. Jumping around, inserting, deleting, creating a structured document quickly, efficiently, and ‘at the speed of thought’ started to make me full of vim and vigor giving me the courage to go further. Further, doing this without a deadline really opened up the opportunity to dig deep and figure out how to use the strange powers of Vim to do what I wanted it to.

Coding

Ok! Now we can get around a little and sort of write things, maybe now it’s time to write a little piece of code. Start with something small, something like your favorite React tutorial, or maybe a code base you know very well, but something that’s going to require you to navigate the code tree as well as write something.

<,f> where <,> is the remapped leader (see your .vimrc) and the f is for CtrlP fuzzy find. Nerdtree is nice for seeing things and getting a lay of the land. But for jumping around quickly and not worrying about your buffers, CtrlP is awesome. I think of it as leader-find and have found it to be the single most important thing for moving around a project when I’m editing, because I’m likely to know where I want to go and don’t need the context of the surrounding files from Nerdtree.

Next, copy and paste. I’m definitely still learning this but yy for yanking things out and p for pasting them in is a good, nondestructive place to start.

Finally, for when you have “blurgh” and want to change it to ‘blurgh’: cs”’, meaning change surrounding double quotes to single quotes. Read more about vim-surround here.

Resources and What’s Next

As always, we stand on the shoulders of giants. Here are some of the posts I used as I was learning:

I am by no means an expert and haven’t even fully immersed myself into the trough of despair, which I expect to be horrible. I’m excited I’ve broken through that initial barrier, and hope with practice, some compassion from my fellow developers, and a little blessing of the Vim gods, I’ll become more and more proficient in my Vimness. If you are learning it now or want to, I hope some of this has been helpful to get you through the initial barriers.

Finally, as with all tech and tools, it is worth noting there is no one true way to learn, and beware of the suggestion that there is a ‘real’ way to learn Vim. Learn it in a way that works for you.

If you have any suggestions or if you think I missed anything, please let me know!

Senior, Lead, or Principal developer in NYC? Stride is hiring! Want to level up your tech team? See how we do it! www.stridenyc.com

Originally posted on the Stride Blog. Author: Nichol Alexander


Published by HackerNoon on 2018/05/09