Initial Thoughts on Vim
Tags: beginners, vim, productivity, tools
Published: 2018-11-20 22:39:36

---
title: Initial Thoughts on Vim
published: true
description: What have I gotten myself into?
tags: #beginners, #vim, #productivity, #tools
---

After reading [Jaime González's](https://dev.to/vintharas) excellent [post](https://dev.to/vintharas/exploring-vim-4k1i), I decided to make good on my previous empty threats to learn Vim. I think what held me back was the fact that I'd already taken the plunge with Emacs so I don't need this hassle in my life. Besides if I have time to learn Vim, I should learn more Emacs. That's all perfectly reasonable, but as it happens I do have a persistent, nagging hole in my workflow, and this seems like it might just be what I need. Or at least do a better job than what I currently have. 

I thought I'd share my thoughts, perspective, and a few things I've learned so far. I'm about a week into learning Vim as I write this, and I am pleasantly surprised at my progress. When I was learning Emacs I was no where near this capable at this point. To be fair to Emacs though I have a good deal of hindsight this time around. I still have plenty of work to do getting my Vim setup where it needs to be, but I'm okay with that. I'm working on the fundamentals and getting those down cold. I don't want to get ahead of myself and add too many plugins too fast. Even though I basically know the kinds of things I want and why I want them, if I'm dumping them all on myself at once I won't understand them or know how to use them. So I'm taking my time, and adding functionality at my brain's rate of adoption. 

If you're just starting out like me you'll find just about everyone will tell you to start with vimtutor. I will uphold that tradition, but I'll raise you a Pro Tip. Don't do vimtutor once. Do it once A DAY, EVERYDAY for no less than a week. It doesn't take long, and will take even less the more you do it. I would also recommend you don't go crazy with plugins and loading up your vimrc file right away. Pick out a theme if you want to, and add a few basic settings just to get the ball rolling.

## A Basic Config
After googling around I came back with what I think is a pretty good start to a vimrc file. I also added a theme, NerdTree, and the airline plugins, but I've omitted them here for simplicity's sake. I've listed the core settings below, and I'll briefly describe each of them after the block. 

```vim
set nocompatible 
syntax enable
filetype plugin indent on
set autoindent
set ruler
set number
set cursorline

" Tabs
set tabstop=2
set shiftwidth=2
set expandtab

" Finding files
set path+=**
set wildmenu
```

Apparently Vim assumes you want to be backwards compatible with Vi, and **nocompatible** corrects that giving you the full IMproved experience. **syntax enable** turns on syntax highlighting. The next line does a few things. Vim will attempt to identify the type of file you're loading, looks for the built-in plugin for that file type, and it's associated indent file which defines the indentation behavior. **set autoindent** will set the next line of text you type at the same indentation level as the current line. **set ruler** displays the row and column numbers for the current cursor position down in the status line. **set number** displays line numbers down the left side of the window. **set cursorline** highlights the line the cursor is currently on.

This next block might be a bit controversial. **set tabstop** sets, as you might have guessed, the width of a tab. I believe the default is four, but I prefer a tighter look so I set mine at two. **set shiftwidth** determines the depth of indentation, and this applies when Vim is autoindenting for you or when you use the indent in and out commands (**<**, **>**). **set expandtab** converts tab stops to however many spaces it takes for the equivalent distance.

The last bit comes courtesy of Max Cantor. These last two commands set up fuzzy file search. We begin by setting the path, or appending to the path variable rather, with the += operator.  The double asterisk is a special wildcard that only matches directories. Specifically, it tells Vim to search down a directory tree. So you can be in the root of your project folder and Vim will recursively search all the subdirectories for the file you have specified. Well, it will search up to 30 levels of subdirectories by default. You can specify more or less by appending a number to the command up to a maximum of 100 and a minimum of 0. So for instance to max it out you can say…

```vim
set path+=**100
```

Now when you use :find Vim will look for the file throughout your project, you can use tab-completion when entering the file name, and use the asterisk glob to make it even fuzzier. Suppose you type in \*_test.rb and there is more than one match. **set wildmenu** provides a list of all the matches. You can press tab to move forward through the list or shift-tab to move backwards.

There is one last search tip I'd like to mention, but it requires familiarity with Vim buffers. Here is a quick and [friendly introduction](http://www.miriamtocino.com/articles/vim-buffers-tabs-windows-and-modes) to buffers, windows, and tabs. But in a nutshell, you can think of buffers as the memory space for each file you have open. They are not necessarily visible at any given time, but when they are it is the job of the window to display it. A window can display only one buffer at a time. A buffer can be summoned several different ways. One way is to type :b _filename_. But you don't have to type the whole filename. You don't even have to type the beginning of the filename for tab completion. Any unique substring that appears anywhere in the name will do. And that comes free; no additional configuration required.

The next item on my docket is a deep dive into text objects. For anyone interested, there is no shortage of resources out there, but [this](https://blog.carbonfive.com/2011/10/17/vim-text-objects-the-definitive-guide/) should get you started.

Some things are fine, they're no big deal. Other things seem more difficult than they ought to be. It feels difficult because I stepped into it not knowing anything, and all my previous experience didn't buy me much. In some cases that experience is working against me. Intellectually I knew that going into it. Knowing a thing is all fine and well, but being in the thick of it is something else. I do think Vim is kind of an all or nothing proposition though. I made that mistake with Emacs and wound up having to relearn it several times. Vim with its modal nature will I suspect make a part-time relationship even more difficult, at least in the beginning.

Something else to keep in mind, there's a danger of falling into a deep, dark hole of yak shaving. You can't spend all your time learning more and more commands, plugins, and endless customizations. That's the opposite of productivity. I fear there is a delicate balance between penny wise and pound foolish. 

If you are not already a Vim aficionado, and if the prospect of becoming one sounds really... awful, that's okay, I dig it, and I respect it. This doesn't have to be for everyone. Long term I don't know yet if it's going to work for me either.  But for now it's filling a gap, I'm getting up to speed pretty quickly, and I have to say overall I'm enjoying it. It's satisfying my inner tinkerer. I still like Emacs, I'm not giving it up, and I think I'm always going to prefer Lisp to Vimscript. But I'm seeing the attraction here.

### Postscript
I'm thankful to Bram Moolenaar for creating this thing, and all the people who have contributed to it over the years.

I'm thankful to [Ben Halpern](https://dev.to/ben) and team, and the whole dev.to community. 

I'm thankful to be here to write and write about code.

Most of all I'm thankful for my family.
> There is no greater happiness for a man than approaching a door at the end of a day knowing someone on the other side of that door is waiting for the sound of his footsteps.
—Ronald Reagan

Happy Thanksgiving everyone.