The ‘Y’ (why)  in vimrc 
Tags: vim
Published: 2018-04-04 05:56:30

---
title: The ‘Y’ (why)  in vimrc 
published: true
tags: vim
canonical_url: https://mohit.io/blog/the-y-why-in-vimrc-part-1/
---

![vim image](https://www.vim.org/images/vim_editor.gif)

I am an avid [vim](https://www.vim.org/) user.  I have used [GVim](https://www.vim.org/download.php#pc) on Windows and now I use [MacVim](http://macvim-dev.github.io/macvim/) on Mac.  I also use it from the terminal when I need it.   There are many reasons why I love vim but this post is not about that or a tutorial on vim.  If vim is your editor of choice,  you will enjoy this series as I will share “why” [my vimrc](https://github.com/technochakra/config/blob/master/vimrc) looks the way it does.

I have read that many folks prefer a standard out of the box tool and don’t like customizing it.  I, on the contrary, like to configure vim to my exacting needs.  My vimrc is a result of my ideas and a number of copy-pastes from fellow vimmers who have shared their configurations over the internet.

## Managing the vimrc file.

In this first part, I talk about the vimrc file itself and some tips to manage it.

### Make vimrc always available: 

Your first goal should be that when you set up a new computer, you should be able to configure your favorite editor in the least amount of time.   Most of my settings and plug-ins are in my vimrc file.  I install all plug-ins through a plug-in manager (more on that later).

To be productive in the shortest amount of time, I require my vimrc to be available to me ASAP.  I achieve this through the following ways.

1. I publish my vimrc to a public [github.com repo.](https://github.com/technochakra/config/blob/master/vimrc)  Make sure you remove proprietary stuff that you don’t want to share  from the file before submitting it in your public repo.
2. My vimrc is located within my data folder – a folder that contains stuff I care about. This data is regularly backed up. So, even if I don’t have access to github.com, I usually do have my vimrc available to me through the backup.

I don’t use the vimrc in the default location.  I always sync the file to a folder such as ~/config and then I modify the default vimrc file and source the file that I synced.

```
cd ~
git clone https://github.com/technochakra/config.git
echo so ~/config/vimrc > ~/vimrc
```

### Configuration is code.

As noted above, I check-in my vimrc file to github.   If you are a software developer, we have reached the age where code, infrastructure, configuration should be treated as code and regularly checked in.  vimrc falls squarely in that category as well.

Reconstructing your vimrc file from scratch is painful and should not be done.

### Avoid the defaults:

I realized recently that my vimrc file contained some obvious defaults.  If you look at the help of a setting and it defaults to what you need, you don’t have to have it in your vimrc file unless some plugin is overriding your defaults.

```
help errorbells
```

In the example above, errrorbells (a beep in case of an error) is **off** by default.  So, your vimrc file does **\*not\*** need the following line.

```
set noerrorbells
```

Having a minimal vimrc file makes it more manageable and it takes you less time to figure out the setting when you revisit it after a few years.

### Source vimrc as soon as you write it 

The following command sources my vimrc file as soon as I modify it.  This helps me try out my changes immediately, fix errors right away and gives me a vimrc file that always works.  It is also very satisfying to see your settings take effect immediately.

```
autocmd bufwritepost vimrc source ~/config/vimrc
```

This does not work when I modify the plug-ins I use but I’ll cover that later.

### Lint free vimrc

As noted above, I like to treat my vimrc file like code.  Well, then there is no excuse not to statically analyze it for warnings and errors.  I use [vint](https://github.com/Kuniwak/vint) as my lint program.  For some reason, vint didn’t work on MacVim when called from plugins that integrate with it so I ended up using vint from the command line.

```
vint ~/config/vimrc
Sample output: <some_path>/vimrc:1:1: Use scriptencoding when multibyte char exists (see :help :scriptencoding)_
```

vint is a great tool to avoid common mistakes.  For example, I did not know about augroups until the tool flagged them for me.

```
<some_path>/vimrc:31:3: autocmd should execute in an augroup or execute with a group (see :help :autocmd) 
<some_path>/vimrc:32:3: autocmd should execute in an augroup or execute with a group (see :help :autocmd)
```

It turns out that by putting autocmds in an augroup, and clearing the augroup using the autocmd! command, you prevent duplication of autocmds in your augroup when your source the file again.   This keeps things clean and optimal.

```
augroup NERDTREE 
autocmd! 
autocmd vimenter * NERDTree
augroup END
```

 

Managing your vimrc file is fairly simple.  It helps to constantly clean it up and keep it minimal.  Now that we have the structure for maintaining our vimrc file, I will discuss the settings I use in subsequent posts.