The Absolute Bare Minimum
There is a bare minimum that you should have in your vimrc file. And let’s face it, we’re not interested being compatible with Vi here. We want the full power of Vim at our fingertips here, so let’s go that way, shall we?
" Forget being compatible with good ol' vi
set nocompatible
" Get that filetype stuff happening
filetype on
filetype plugin on
filetype indent on
" Turn on that syntax highlighting
syntax on
" Why is this not a default
set hidden
" Don't update the display while executing macros
set lazyredraw
" At least let yourself know what mode you're in
set showmode
" Enable enhanced command-line completion. Presumes you have compiled
" with +wildmenu. See :help 'wildmenu'
set wildmenu
" Let's make it easy to edit this file (mnemonic for the key sequence is
" 'e'dit 'v'imrc)
nmap <silent> ,ev :e $MYVIMRC<cr>
" And to source this file as well (mnemonic for the key sequence is
" 's'ource 'v'imrc)
nmap <silent> ,sv :so $MYVIMRC<cr>
We’ll leave it there for now… that should do for the absolute bare minimum, I would think. Opinions will vary, for sure :)
A note on “hidden”
Ben Fritz (a real Vim guru) suggested that I explain the ‘hidden’ option and why I think it’s such a good thing. He rightly points out, of course, that it’s not the only way to do things (as can be said for nearly every feature of Vim :D), but it’s definitely something I consider crucial.
Hidden buffers are described pretty well right at the buffer-hidden part of the Vim help but in short, by setting ‘hidden’ you’re telling Vim that it’s OK to have an unwritten buffer that’s no longer visible. If you’ve got 12 buffers and 2 windows then there are 10 buffers that aren’t visible and if you set ‘nohidden’ then that means that those 10 buffers must be written to disk. If they aren’t written to disk then they would have to be visible. I prefer to have buffers that aren’t visible and need not be written first. Vim keeps me safe from quitting altogether while having unwritten buffers so there’s no chance of accidentally losing data.
The reason I think it’s such a great feature is for a few reasons:
- I don’t use tabpages.
- I load a lot of files and they can’t all have their own windows.
- I believe in having only one Vim session.
- I modify a lot of buffers with single commands using :bufdo.
- Typing :wa once in a while instead of :w once in a while isn’t such a big deal.
Using set hidden allows me the kind of workflow I like, which is one that is highly flexible for the things I do – lots of modifications on a global scale or even on a sub-global scale. I’ve forgotten just how convenient it is. What I do notice is that when I use another person’s Vim that doesn’t have it set, I hit the ‘nohidden’ wall after about half a dozen keystrokes and say “Argh!” :)
Ben Fritz:
September 27th, 2009 at 7:02 am
(NOTE: This comment was moved from my old website (derekwyatt.wordpress.com) to this one. This is a verbatim copy)
Regarding “set hidden”:
While I agree that it is a very useful option for many people, others like me will find that it does not fit into their workflow.
The ‘hidden’ option means that when you abandon a buffer (usually because you open a different file in the same window), Vim will quietly put the still-modified buffer in the background. Eventually, you may have many modified files loaded (but not viewed) in Vim, with no visible indication that this is so. If you don’t remember to check for such “hidden” buffers before doing things like compiling, the results may surprise you.
‘hidden’ is a great option for many, many people, especially people who like to keep a single Vim window open at a time. But there are other ways of working with Vim, including a “Rolodex style” multi-window look, or using the tab pages introduced in Vim 7.0. If you like to keep all your modified buffers visible so you don’t forget them, then ‘hidden’ is probably not for you.
Nevertheless, one of the wonderful things about Vim is that it provides great options to fit almost any work style.
Instead of (or in addition to) ‘hidden’, I’d encourage users to also take a look at ‘confirm’ and ‘autowriteall’. As for this “bare minimum” example, at least explain what ‘hidden’ does.
Great work on all this by the way, Derek. You’ve provided a great resource.
Mike B:
October 12th, 2009 at 7:04 am
wow. wildmenu is *magic*. thanks for the heads up on that one!
Moerk:
July 17th, 2012 at 4:06 pm
Is there a way to combine the “edit vimrc” and “source vimrc” part, so you have one command that opens the file, and after you closed it, it automatically sources it?
I know you can put a kind of file listener on it, but just wonder if you can combine them to one command.
Derek Wyatt:
July 17th, 2012 at 4:29 pm
Not that I’m aware of. I think what you’re trying to do is make a mapping that does something like:
nmap ,ev :edit ~/.vimrc — do whatever you want — wait for buffer to die — :source ~/.vimrc
Can’t be done. You need to put the file listener on there. Listen for the buffer delete (or whatever is appropriate) and when it matches the vimrc file, source it. It’s really quite simple, actually. Giver ‘er a go.
Zak:
July 22nd, 2012 at 9:30 am
@Moerk – I think this is kinda what you’re looking for, I have this in my vimrc:
” re-source .vimrc on save so changes are effective immediately
if has(‘autocmd’)
autocmd! BufWritePost .vimrc source %
endif