I recently migrated my life from one laptop to another. I decided to take the opportunity to start over pretty much from scratch with regard to my
.vimrc file — the configuration file for Vim, my editor of choice. Among the things I wanted to do is get something cleaner than I had in my old
.vimrc, which had accumulated a lot of aliases/abbreviations I no longer use, among other problems; get proper indentation support for the various types of writing I do; and make folding usable. I was surprised at how easy all this stuff turned out to be, once I really looked into it.
As I mentioned in Vim + Scheme, I had some difficulty getting Scheme-friendly indentation and indentation more friendly for the rest of the work I did actually “just work” when I wanted them to. In the course of my investigations, though, I determined that it was actually trivially easy to configure Vim to not only handle that problem, but also handle some of the non-Scheme indentation I use even better than it had before. The key for this particular issue turned out to be something that I still haven’t found clearly documented in a discoverable location (including various Weblog posts that purport to provide “good” Scheme indentation configurations for Vim, but at best give me exactly what I’m getting now without the automatic fallback to non-Scheme indentation when I’m not editing a Scheme file).
Without further ado, my current, new
.vimrc looks a little something like this:
filetype plugin indent on set autoindent set shiftwidth=2 set backspace=indent,eol,start set expandtab set history=50 set nocompatible set nomodeline set ruler set nofoldenable set fdm=indent
Because I’m annoyed by all the “helpful” stuff I encounter when trying to figure out how to configure Vim that presents a bunch of cryptic configuration without leaving me any sense of how any of it works, I figured I’d explain the above
.vimrc contents in excruciating (and hopefully useful) detail.
This line tells Vim to detect the filetype primarily by its name, which makes
foo.scma Scheme file and
foo.rba Ruby file. Secondarily, there are filetypes that are determined by the file’s contents in some magical manner that is not entirely clear to me, but might in some cases involve looking at the shebang line in scripts. Having done this, it then turns on plugins and indentation schemes for the filetype in question. Only
indentis necessary to get nice, clean, helpful Ruby indentation rules, but Scheme indentation doesn’t work properly without
plugin, so both are necessary for my purposes.
This handles the general case for indentation, which just maintains the current level of indentation when creating a new line above or below the current line. I have yet to see any other automatic indentation in any editor that works better for doing plain English writing; automatic paragraph indentation in software like MS Word and OpenOffice.org is far more trouble than it’s worth.
I ended up having to set this value to
2so that Ruby indentation wouldn’t use 8-character indentations, which is hideous with Ruby, as any Ruby programmer should know. Since I’ve developed an aesthetic appreciation for two-space indentation in basically any language, this setting is perfect for me.
Depending on the default configuration of Vim on your system, this may or may not be necessary. It was necessary for me, to ensure that backspaces would work properly:
- on indentations
- across newlines
- on newly open files
Actual tab characters are usually evil. For this reason, I have
expandtabturned on in Vim, which means that tabs get turned into a number of spaces equal to the character width of the tab. The exception I occasionally encounter to the “tabs are evil” rule is the case where one must copy tabs faithfully from an outside source, but it’s rare enough that I guess I can suffer with the requirement of explicitly turning off
expandtabwhen needed. I’ve searched and searched, and there doesn’t seem to be any way to make Vim do the
expandtabthing normally but faithfully preserve tabs pasted from an outside source. Yes, I really have found a limitation to Vim, finally.
Simply put, this ensures that I can perform up to 50 undo operations, and redo them afterward, if need be. If I have more than 50, I have probably been going way too long without committing to a version control system anyway. Realistically, I should never actually run as high as half this many undo operations under any reasonable circumstances.
This is just here so Vim doesn’t act too much like legacy vi, and do things like inhibit my ability to work. For instance, using
uto undo an operation in Vim can normally be done more than once for multiple undo operations, but in vi (and in Vim’s vi-compatible configuration) the second time in a row you use it just undoes the last undo. This is not acceptable to me.
Sadly, it seems that
nomodelineis necessary in Vim for security purposes. It seems like every six months there’s a new Vim vulnerability, where the work-around to ensure you’re protected is to set the
nomodelineoption. Since I never actually use
modelinefeatures anyway, I just leave this set all the time.
This gives me line and column indicators at the bottom of the Vim window. For instance, the point at which I start typing the first instance of the word “word” in this sentence is line 65, column 154 of the file (which is to say the W in “word” is character 154 of the 65th line) when I edit this in Vim.
I want folding in Vim so I can “fold” functions, decluttering the screen — but I want it on my terms. If folding is enabled by default, everything’s folded when I first open a file, which I find annoying. If I want it folded, I’ll fold it myself, using
zcommands, dammit. If I really want everything folded the way it would start out by default with folding enabled, I could use
Setting this to
indentuses the indentation style applied to the current file to determine how to fold things. The
fdmevidently stands for “fold method”. There’s probably a better fold method for my purposes, but I haven’t found it yet — and having to set markers is just more work than it’s worth.
I may add more later, but that’s it for now.