Vim is an editor designed to work like that most venerable of UNIX editors, vi. Vim doesn't just clone vi; it extends vi with features like multi-level undo, a graphical interface (if you want it), windows, block operations, on-line help and syntax coloring.
Along with the new features, Vim 5.5 (the current version as I write) has 196 options you can set. Practically any behavior you might have found obnoxious in plain vi can be configured to your liking in Vim. To download or get more information on Vim, see the Vim home page at http://www.vim.org/. Within Vim, you can view the on-line help at any time by pressing ESC, typing :help and pressing ENTER.
I'll admit that the thought of trudging through 196 options on the off chance that one or two will do what I want might seem a bit daunting, so here are several of my favorite Vim customizations just to get you started. These customizations have saved me much frustration and helped make a regular Vim user out of me.
Before I talk about specific Vim customizations, however, let me explain how to save your customizations so they are loaded each time you start Vim. When you first start using Vim, it will be 100% compatible with vi. You won't notice any of Vim's fancy features until you activate them.
This behavior is nice: it allows system administrators to replace /bin/vi with a link to Vim without their users rising up against them screaming, “vi is broken. Fix it!” In fact, some people have used Vim for years this way without realizing they were using anything fancier than vi. But strict vi emulation can confuse people who expect to see all of Vim's bells and whistles right from the start.
Luckily, it's easy to convince Vim that we know we're actually in Vim and not in vi. Vim customizations are stored in a file called .vimrc in your home directory. If Vim sees that you have a .vimrc file—even if that file is empty—Vim will turn off vi-compatibility mode, which will configure Vim as Vim, rather than vi.
If you don't have a .vimrc file, but you do have an .exrc file that you have used to customize your vi sessions in the past, execute the command
mv ~/.exrc ~/.vimrc
to rename your .exrc file to .vimrc.
If you have neither a .exrc file nor a .vimrc file, execute the command
to create an empty .vimrc file.
You're now ready to begin configuring Vim in earnest. You can add commands to your .vimrc file in the same way you would add them to your .exrc file. That is, if you tried Vim's incremental searching feature (which I'll describe shortly) by pressing the ESC key and entering the command
and decided you wanted to make incremental searching the default behavior for future Vim sessions, you could do it by putting the line
set incsearchinto your .vimrc file on a line by itself. Note the lack of a leading colon.
Suppose you have the following text file to edit:
In Xanadu did Kubla Khan A stately pleasure-dome decree: Where Alph, the sacred river, ran Through caverns measureless to man Down to a sunless sea.
Your cursor is on the I in the first line. You need to get to the first occurrence of the word “measureless”. How do you do it?
One way is to press / to put Vim into search mode, type in “measureless”, and press ENTER. Vim will find the first “measureless” after the current cursor position and leave your cursor on the m. Easy, in principle, that is. I'm not such a great typist. When I try to search forward for the word “measureless”, I'm just as likely to misspell it as not. And if I misspell it as “measurless”, I won't realize my mistake until I press ENTER and Vim returns “Pattern not found: measurless”.
I could increase my chances of typing the search pattern correctly by searching for a substring of “measureless”. For example, if I search for “measu”, I have fewer characters to type, which means fewer ways I can mistype my search pattern. However, that means I have to guess how many characters will specify a unique substring of the word I want to find. If I don't type in enough for my search pattern, I'll end up in the wrong location. For example, if search for “me”, I'll end up in “pleasure-dome” on line two rather than where I want to be, which is on line four. I'd then have to search again by pressing n.
Vim's incremental search feature can help with both of these problems. To try it out, press the ESC key to enter command mode, then type
and press ENTER.
Incremental searching means that as you enter your search pattern, Vim will show you the next match as you type each letter. So when you start your search for “measureless” by pressing m, Vim will immediately search forward for the first m in the file following the current cursor position. In this case, it's the m in “pleasure-dome” on line two. Vim will then highlight in the text the pattern it has matched so far for you. Since “pleasure-dome” isn't where you wanted to go, you need to type more letters in your search pattern. When you press e, “pleasure-dome” still matches the substring me, so Vim will highlight the “me” in “pleasure-dome” and wait for more input. When you press a, “pleasure-dome” no longer matches the substring mea, so Vim will highlight the next match for mea, which is “measureless” on line four. Jackpot! Since that's the word you are looking for, press ENTER, and Vim will leave your cursor on the m in “measureless”.
With incremental searching, you always know what the results of your search will be, because the results are highlighted on your screen at all times. If you misspell your search pattern, Vim will no longer show you a highlighted match for your search pattern. When your highlighted match string disappears from the screen, you know immediately that you should back up by using the BACKSPACE key, and fix your search pattern. If you change your mind about what you wish to search for, you can press the ESCAPE key, and Vim will return the cursor to its previous location.
- New Products
- Handling the workloads of the Future
- Readers' Choice Awards 2014
- Android Candy: Google Keep
- How Can We Get Business to Care about Freedom, Openness and Interoperability?
- Days Between Dates?
- diff -u: What's New in Kernel Development
- December 2014 Issue of Linux Journal: Readers' Choice
- The Awesome Program You Never Should Use
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane