Help File Library: Customizing vim

Written By: Danny "Strike" DiPaolo

This article is intended for the following types of Linux users:

• programmers (from novices to hobbyists to seasoned coders)
• people who use markup languages like HTML and/or LaTeX
• anybody who really loves their vim and wants to make it even better

That being said, I'm going to assume you are one of the above people if you are reading this article. However, keep in mind that I use vim for all of the above reasons, so disregard anything that you think may not apply to your needs.

This article will also assume that you are at least fairly familiar with the vim editor. I'm not sure how far back this Help File will apply in terms of the format of the config files, but I am using 5.6.11 right now (5.7 is the most recent, I believe). If you are unsure, just get a new version by navigating their website at http://www.vim.org . But, for example, you ought to know that vim is not a mode-less editor, and you should at least be somewhat familiar with both command mode and input mode as well as entering commands at the vim prompt (the colon [:], like :wq for writing and quitting).

---Organization---

Note - what I'm suggesting here is exactly that, a suggestion, nothing more. There may be better ways of organizing things, but this is the way I like to do it because it fits in well with the rest of my directory structure.

First of all, there is one file whose place is not at all optional. This is your .vimrc file. This MUST be in your home directory. This file will also pretty much be the key to all of our customizations. So, in case I haven't gotten this point across - this file is IMPORTANT. If you want to keep your customizations, I'd suggest backing it up somewhere in case of a power failure which crashes your system or in case you want to move it to another system.

However, there are other configuration files that we will be using. These begin to grow in number pretty quickly, and I don't like having a lot of unsightly dot-files (files beginning with a .) in my home directory - there are already plenty of dot-directories - so what I did was that I created a directory that was designed specifically to hold my other vim configuration files.

I called this directory .vim-files because it's a good descriptive name and it doesn't show up on a simple ls (configuration stuff like that really should not in the first place). Every other file I will talk about will either reside in this directory or a subdirectory of that directory.

To create this directory, issue the following commands:
cd
mkdir .vim-files

The first cd will just put you in your home directory, and the second command actually creates the directory.

Once that is set up, we are ready to start digging into the .vimrc for some serious configuration goodness!

---The ~/.vimrc file---

Before we get too deeply involved, I want to give you an idea of just how configurable vim is. So, fire up a session of vim in a terminal window. Get to the colon prompt and type "set " (with a space) and then hit <TAB>. If you weren't aware of this feature before, vim has tab-autocompletion for all of its commands as well as filenames and such. But, you should get something like "set all" (that's what I get). Hit <TAB> again, and again, and again. Hold down <TAB> for a while. What you see whizzing by are all the different options that you can set for vim. Some of them are usually pretty obvious and have reasonable defaults. Some of them are highly dependent upon what the user is accustomed to. Some of them are highly esoteric and generally aren't ever even worried about. But, sure enough, there are a lot of them.

If you want to take full control of your vim sessions, here is what I suggest you do before proceeding. Do the procedure I outlined above, but more slowly - read each option as it goes by, and if there are ones that you are interested in using for your configuration, jot them down. The same goes for ones you aren't sure of the meaning for (like "what does 'set cscopeprg' mean?"). Once you have these lists, get back to a colon prompt and just type ":h " and then the option that you were curious about. ":h" is the online help in vim. It is VERY extensive, and you are highly encouraged to poke around the help files they provide. Make sure that you keep a list of things you are interested in setting as well as any particular values that you need to set them as. This is essentially what I did to create my own .vimrc, and it has paid off.

Of course, these are just options to be set. We will be doing a little bit more than that in this Help File, because ... well, because we can and because it makes vim a much more powerful tool.

Now, I'm sure that if you are one of the people I described as the type who should be reading this Help File that you have at least had at least a little bit of experience with configuration files like this before. But, one way that this one is a little different is that it can basically be thought of as a script. Honestly, I could delete my .vimrc file from my computer if I was willing to enter all 40+ commands manually at the colon prompt every time I started up a session of vim. But, trust me, that won't happen. However, the fact that vim simply executes all of your .vimrc commands at the startup as if you were entering them manually is helpful to us because of the feature I mentioned earlier - command tab-autocompletion. This, combined with the very extensive online help that vim provides will make you able to take what I show you here and add any other interesting command that you want.

I know what you are thinking - you want to go ahead and dig in already, right? Good, me too. There's just one more thing I have left to mention before I show you all my current ~/.vimrc file, and that is the comment character. The comment character in the ~/.vimrc file is the double quotation mark ("). Every character after that one on a line is considered a comment and will not be part of the script. There are no block comments in ~/.vimrc files.

Okay, enough of that, here is my lovely ~/.vimrc file:

----------------------------

" Formatting
set tabstop=4                   " tabs are 4 spaces
set bs=2                                " backspace over everything in
insert mode
set smartindent                 " does C-style stuff

" Mouse stuff
set mousehide                   " hides mouse after characters are typed
set mousefocus                  " no real reason for this
set mouse=a                             " mouse in all modes
set mousem=popup                " Right mouse button pops up a menu.
Shift-left extends selection      

" Other stuff
set autowrite                   " writes on make and shell commands, etc
set     ruler                           " Turn the ruler on
set nohlsearch                  " Highlighting found search items is
annoying
set nocompatible                " vi compatibility is weak

" set suffixes to ignore in command-line completion
set
suffixes=.bak,~,.o,.h,.info,.swp,.aux,.bbl,.blg,.dvi,.lof,.log,.lot,.ps,.toc

" run ispell on current file
" map #fi :w:!ispell %:e %
" 
" I'm not sure what key that is mapping to, or if it is just the key
" sequence specified ..

" Remove ALL auto-commands.  This avoids having the autocommands twice
" in case the .vimrc file gets sourced more than once.
autocmd!

" LaTeX autocmds
autocmd BufRead                 *.tex   source ~/.vim-files/.vimrc.latex
autocmd BufNewFile              *.tex   source ~/.vim-files/.vimrc.latex
" C autocmds
autocmd BufRead                 *.c             source
~/.vim-files/.vimrc.c
autocmd BufNewFile              *.c             source
~/.vim-files/.vimrc.c
" asm autocmds
autocmd BufRead                 *.s,*.S,*.asm   source
~/.vim-files/.vimrc.asm
autocmd BufNewFile              *.s,*.S,*.asm   0r
~/.vim-files/skeletons/skel.asm      
autocmd BufNewFile              *.s,*.S,*.asm   source
~/.vim-files/.vimrc.asm
" HTML autocmds
autocmd BufRead                 *.htm,*.html    source
~/.vim-files/.vimrc.html
autocmd BufNewFile              *.htm,*.html    0r
~/.vim-files/skeletons/skel.html
autocmd BufNewFile              *.htm,*.html    source
~/.vim-files/.vimrc.html
" Perl autocmds
autocmd BufRead                 *.pl    source  ~/.vim-files/.vimrc.perl
autocmd BufNewFile              *.pl    0r ~/.vim-files/skeletons/skel.pl
autocmd BufNewFile              *.pl    source ~/.vim-files/.vimrc.perl
autocmd BufWrite                *.pl    !chmod +x %
" Java autocmds
autocmd BufRead                 *.java  source ~/.vim-files/.vimrc.java
autocmd BufNewFile              *.java  source ~/.vim-files/.vimrc.java

" Only do this for Vim version 5.0 and later.
if version >= 500

if has("terminfo")
  set t_Co=8
  set t_Sf=[3%p1%dm
  set t_Sb=[4%p1%dm
else
  set t_Co=8
  set t_Sf=[3%dm
  set t_Sb=[4%dm
endif

endif

" And of course, the ever important syntax highlighting
" This has to go last because of the if stuff above
syntax on

-----------------------------------------------------

This is actually just a preliminary version, I know that it will grow to be much larger than it is now simply because I haven't added all of the languages I code in to this one yet (most notably, C++ is missing).

I'm pretty liberal with my comments in here, because some of the options I set were ones that I just looked up once and forgot after that. So, if I'm ever tempted to delete certain lines, most of them have a description that will tell me what I'd be deleting by doing so. It's also a good idea to break it up into logical blocks, setting options that are similar in the same blocks, instead of just all over the place.

A quick look at the options reveals a fair amount about how I like my vim working environment. But, truth be told, setting the options for vim is hardly the most exciting and/or versatile thing we will be doing. So, pardon me if I simply gloss over them. Besides, I explained before of a good way to find new options to set and how to set them.

The real strength in my .vimrc lies in the autocmd section. You may be saying, "What are autocmd's?" Well, a quick ":h autocmd" (remember, if it's in our .vimrc file, it's just a command, and we can get help for commands with the online help with ":h <command>") puts us in the autocmd.txt help file which tells us:

--------
You can specify commands to be executed automatically for when reading or writing a file, when entering or leaving a buffer or window, and when exiting Vim. For example, you can create an autocommand to set the 'cindent' option for files matching *.c. You can also use autocommands to implement advanced features, such as editing compressed files (see |gzip-example|). The usual place to put autocommands is in your .vimrc or .exrc file.

WARNING: Using autocommands is very powerful, and may lead to unexpected side effects. Be careful not to destroy your text.

If you didn't believe me before when I said that autocmds are the real strength, hopefully you do now - even the authors acknowledge the power of autocmd's.

Now, if you do what I did above (":h autocmd"), you will get to a great source of help for autocmd's. But, if you don't want to pour through that very very comprehensive help file, we'll take a look at exactly what I've decided to do for my own setup and leave the help-file perusing for later.

Now, it's pretty obvious that I have 7 major sections of autocmd's in this file.

The first section is this:

------------

autocmd!

------------

That's it. And, like the comment above it says, this just removes all currently defined autocommands just so that we know exactly what is going on, in case a separate autocommand got stuck in the process somewhere. After all, that's what this Help File is all about - controlling our vim environment and harnessing the power behind it.

The next six sections are each for their own specific language - LaTeX, C, asm, HTML, Perl, and Java. They all follow the same rules, so I'm just going to work with the section that is most complex - my Perl section.

Here it is again:

------------------

" Perl autocmds
autocmd BufRead                 *.pl    source  ~/.vim-files/.vimrc.perl
autocmd BufNewFile              *.pl    0r ~/.vim-files/skeletons/skel.pl
autocmd BufNewFile              *.pl    source ~/.vim-files/.vimrc.perl
autocmd BufWrite                *.pl    !chmod +x %

------------------

Now, what do each of these mean? Well, let's take it line by line (and, for the sake of saving time, we'll go ahead and skip the very first line [the comment that says "Perl autocmds").

First line:

autocmd BufRead         *.pl    source ~/.vim-files/.vimrc.perl

Well, we already know what an autocmd is (from above). Now we have to figure out what "BufRead" means. And, it's not that difficult - it's a lot like you would expect. It means that this autocommand applies every time a buffer is read.

The next part is pretty easy if you are a programmer (or at least know that Perl files have .pl extensions usually). This basically defines what KIND of buffers this autocommand will apply to. In particular, this one will only apply to files ending in .pl.

The very last part is the actual command to be executed. What this command does is that it sources a SECOND .vimrc file - one that stores my Perl-specific macro definitions and such. This is one of those files that I mentioned lived in my .vim-files directory. And, like I said, this is essentially another .vimrc to bbe sourced. But, since they are Perl-specific macros that I have defined in there, I only source them either when I'm editing a Perl script or creating a new one.

As it turns out, this autocommand line handles half of that situation - it applies to when I'm editing existing Perl scripts, but not to when I create new ones (you can't read in a buffer of something that doesn't exist yet). But, I of course took care of that with a different autocmd two lines down. It is the exact same as the first one, only that this time we used "BufNewFile" instead of "BufRead" - that means this autocommand will apply every time a new file is created (with the further constraint that it has to be a file ending in .pl, since it has the "*.pl" as well).

So, that covers half of this section (the first and third autocmds). Next up is the second one:

autocmd BufNewFile              *.pl    0r ~/.vim-files/skeletons/skel.pl

Well, we just learned how to interpret most of this. The first three columns signify that this command is to take place every time a new file is created with a .pl extension. The only thing left to decipher is the command itself. Well, this command (and you may already know it if you have used it in vim before) will place the cursor at the beginning of the file (which is supposed to be blank since we are dealing with new files), and then reads the contents of ~/.vim-files/skeletons/skel.pl into the file. Now, keep in mind, you are never editing that file, it just dumps that file's contents into the current buffer, which in this case is a new Perl script.

But what exactly is in that file? Well, in this specific file is nothing more than a simple two-line header that has been going on all of my Perl scripts as I've began to learn Perl:

------------------

#/usr/bin/perl -w
use strict;

------------------

Instead of having to type this every time I create a new Perl script, I simply created a "skeleton" file that contained nothing but that and I decided I'd just dump the contents of that file in every new Perl script I write. So, if you have a specific task which requires several files that use the same sort of basic skeleton, then I'd suggest that you make this same sort of skeleton file technique.

Now we get to the last autocommand in the sequence (having already covered the third one above):

autocmd BufWrite                *.pl    !chmod +x %

By now, I'm sure the first three are pretty easy to figure out even though we haven't explicitly talked about the "BufWrite" condition. It's pretty much any time that you write (save) the file, this action takes place.

The command, however, may or may not come so easily. The first character, the exclamation point (!) signals vim to invoke a shell to run the commands that follow. Hopefully you are familiar enough with *nix command-line utilities to know that "chmod +x" will make a file executable (but, if not, now you do know). However, the last character is a bit of a mystery. The chmod command requires a filename, but this percent sign isn't the name of our current file. However, this is one of the special vim characters. In vim commands, a percent symbol will always be replaced with the current filename. Another handy substitution like that is to use %< whenever you want the extension removed from the filename. If you follow it up with a different extension, it will append that new extension to the filename. For example, if you are working with a file named foo.tex and you want to output a file named foo.ps, then you could specify foo.ps by using %<.ps - sounds pretty simple, huh? Well, hopefully it is fairly simple. After all, we've just covered one file so far.

Well, with that said, we've more or less covered the biggest parts of the main ~/.vimrc file, and I think it's about time we move into some of those other files that we were sourcing.

--other .vimrc files---

You might be wondering, "Why have other .vimrc files? We've set all the options in the first .vimrc file, right?" Well, the answer to that is yes and no. The options that we set in the ~/.vimrc ARE indeed global and will apply to every file we edit in vim. However, we can do ever so much more with vim. Just wait and see.

There is really only one thing I am going to cover for putting into your task-specific .vimrc files, and that is macros. For all you LaTeX users out there, tell me how this sounds. To run LaTeX on a file while STILL editing it all you have to do is type ,rl (just a key sequence I chose that's easy to remember, for "run LaTeX"). Then, to create a PS (PostScript) file out of it, all you to type is ,cps (again, an arbitrary key sequence chosen to signify "create PS"). And finally, all you have to do to view that file is type ,gv (used since gv is just short for Ghostview, but it was still chosen arbitrarily). In fact, you don't even have to wait for one to finish to do the next. So, to get a PostScript file from your LaTeX source file, all you have to do is type ,rl,cps,gv. In fact, you could make your own macro to do all of these at once if you want to.

Moving right along, there are two major types of macros I'm going to cover - command mode macros and input mode macros. The only big difference is when they are invoked. There are also subtleties in the way you write them as well, as we will see.

:::Command Mode Macros:::

These are kind of like the autocommand commands we specified earlier, only these are not automatic for certain events, but rather they are invoked when you hit a certain sequence of keys. But, you must write them as they would be invoked in command mode, and NOT from the colon command prompt like we did for the autocommand commands (also, this is different from input mode macros, as you will see). Let's take a look at an example or two. These are the LaTeX macros I alluded to earlier:

-------------------------------

map ,rl :w:!latex %
map ,cps :!dvips %<.dvi -t letter -o %<.ps
map ,gv :!ghostview %<.ps &

-------------------------------

Obviously, the key word to define these macros is "map". The next entry is the key sequence needed to invoke the macro (which is easily figured out just by rereading three paragraphs up). The last entry is, of course, the actual sequence of commands to run as soon as the preceding key sequence is entered in command mode.

Let's take a look at the first one. It looks semi-straightforward to me, but that's not exactly an unbiased opinion. Basically all you have to think of to come up with these macros is what keys you would normally hit to get whatever it is you are trying to program done. So, with this macro, what happens is first the colon command prompt is invoked (by hitting : just like you would do in command mode), and then we write the file by typing "w" and then hitting Enter (or carriage return, <CR>). Once it is written, we want to run the LaTeX compiler on the current document. So, we get into command mode (:), and run the LaTeX compiler in a shell on the current file (!latex %<CR>). Simple, huh?

Well, even if it isn't, it comes with practice. The next one is fairly similar. It simply runs "dvips foo.dvi -t letter -o foo.ps" (assuming we were working on foo.tex). That produces a PostScript file from the DVI file that we created with our LaTeX compiler. There's nothing new in this macro, really. Just remember that %< is the current filename minus the extension, and that you can then put any extension you want after it.

The last command, as explained earlier, simply runs ghostview on the newly created PostScript file. The only subtlety about this one is that it makes sure to run it in the background so that we can play around in Ghostview while still playing around in vim. The other commands put a lot of output on the screen (with potential errors), so we didn't run these in the background.

Let's take a look at one last set before moving onto input macros. This set of examples is for editing assembler:

-----------------------

" This will run nasm
map             ,n              :w:!nasm -f elf %
" and ld
map             ,l              :w:!ld -s -o %< %<.o
" and the executable
map             ,r              :w:!%<
" or do the whole thing in one shot
map             ,a              ,n,l,r

Don't forget, the comments can be used in these files as well. The main macro I wanted to use as an example was the last one. Remember before with the LaTeX example when I said you could run all of those commands in one? Well, this is a really simple way of doing it. The ",a" macro in this set of macros (which resides in my ~/.vim-files/.vimrc.asm file that is referred to in my main ~/.vimrc above) simply runs the first three macros in order. Another way I could have done this would have been to actually take all three of the commands used in the other three macros and to concatenate them all together. But, it's much much shorter to just run the three things we have already defined. So, instead of having to type ,n,l,r we can save ourselves some keystrokes by just typing ,a instead. Kinda neat, huh?

Okay, that is about all of the really neat stuff to do with command mode macros that I have to show you guys, so the next (and final) step is ...

:::Input mode macros:::

These are very closely related to the command mode macros, but with their own tiny little subtleties. Let's take a look at some examples, this time some examples I use in my C macro file:

-----------------------

map!    ]if             if () {^[o}^[keei
map!    ]for    for () {^[o}^[keei
map!    ]while  while () {^[o}^[keei
map!    ]inc    #include <.h>^[hhi

-----------------------

Now these probably look incredibly cryptic. Part of them may look somewhat straightforward, but if you can get them from just looking at them, I'd be very impressed.

An important point to reiterate is that these macros are all entered while you are actually still in input mode. For example, if I were to type "]if" in input mode, it would perform the first macro (which I will get to the meaning of in a bit). In the same vein, typing something like "]ifa" would first expand the first macro and then put an "a" wherever the cursor ended up after the macro was complete. So, it is important to choose things that you are not likely to actually type in whatever you are typing, because otherwise they will expand to the macros you defined. This is why my macros begin with the "]" character. I don't use the "]" character for anything in C except for arrays, and it is rarely ever followed by words like "if", "for", etc. And even if it was, I do not think it is ever necessary to use it in that fashion - these letter combinations can pretty much always be avoided. However, I also like them to be fairly easy to remember as well, and I think these examples exemplify that as well.

As you may have noticed, we are no longer using "map" to define our macros, but "map!" instead. Well, this is what defines an input mode macro. "map" is only for command mode macros. I generally put these in a separate section from my command mode macros so as not to clutter up my .vimrc files too much so that I can further customize them later.

Okay, with all of that covered, let's tackle what these macros expand to. Much like the command mode macros, you basically think of what keys you want to be pressed, remembering that you start in input mode. Well, I'll go ahead and tell you ahead of time what each of these macros is for in case you haven't already figured it out. The first three are basic macros to create a syntactically correct if/for/while loop quickly. The last one is simply a shortcut for including files, and you will see how it works.

's take a look at the first one. Let's assume we are editing the source code for something and we have these definitions sourced. I'm in input mode and I'm ready to begin an if statement. Normally, I'd just start typing something that might look like this:

-----------------------

        if (a <=

-----------------------

But the problem here is this, I've already decided that I want to use an if statement, but I can't focus entirely on the process that needs to take place within that if statement because I have to remember to close the loop in order to follow syntax correctly. In fact, with normal typing methods, closing the if statement is the last thing you do even though it is the first thing you decide with regards to that program block. True, you could simply type out a basic if statement first so that it was syntactically correct and then fill in the appropriate statements, but that doesn't really apply here now does it?

Actually, yes it does, very much so. In fact, that is exactly what we are going to do. But we will take it one step further. We will reduce that step to a much smaller number of keystrokes (as you will see). Now, a syntactically correct if statement looks like this:

-----------------------

        if () {
                            
        }

----------------------

where the <condition> and <program statements> vary from task to task. So, we want to insert this little bit:

----------------

        if () {
        }

----------------

and then prepare ourselves to start thinking of the condition we want to put in this particular if statement. So, we've got our problem nailed down now. Next we'll see how my macro does exactly what we want.

It's pretty obvious (now that you know what input mode macros do) that most of this is fairly trivial. In fact, the entire first line is very simple, it's just the part that reads "if () {" - since we are in input mode, hitting those keys simply puts them in the file like we want. However, now we have a bit of a problem. We have to move the cursor down a line and input a final "}" and THEN we have to move the cursor back on top of the second parentheses and drop ourselves back into input mode (for the most seamless behavior - we start in input mode, we should end in input mode, we did the same for command mode macros too). Well, there are two ways to advance to the next line, actually.

One is fairly easy, and the other a little tougher but more illustrative. The "fairly easy" method would be to simply to hit Enter and then insert the final brace. However, I prefer the latter method because it is more illustrative. This method is to escape OUT of input mode (yes, into command mode), to begin a new line in input mode with the vi command "o", and to insert the final brace. But, how does one enter in <Esc> as a character into a macro? The only way to do it is to hit CTRL-V while in input mode and then hit the <Esc> key. It produces two characters like this ^[ but it isn't the same if you just type those two characters in (if you do, then you will have a "}^[" at the end of your if statement at this point in time.

Okay, now that we have gotten all the characters in place we have two objectives left to accomplish - positioning the cursor so that we are in between the parentheses (realistically, on top of the second paren), and to make sure we end up in input mode for our seamless transition.

First, let's remember what we've done and where we are. This is what our setup looks like right now:

-------------------

        if () {
        }_

        ---INSERT---

-------------------
(the underscore represents the current cursor position)

Well, now we are going to position the cursor, but there is not any way of moving up a line in input mode, so we have to escape out again. That is what the next ^[ in the sequence is for. This will put the cursor back one spot, directly on top of the curly brace (on the second line). We then want to move the cursor up one line using the vi navigation keys HJKL - the appropriate one for this one is of course, "k". Now our cursor is on top of the "i" in "if" - we have to move it forward to the end of the "word" after it (well, this "word" is just the set of two parentheses, but it will do). So, we put it at the end of "if" by telling it to go to the end of that word (e) and then we tell it to go to the end of the next "word" (e). Now we are in the right position, but have one thing left to do - return to input mode. And any seasoned vi user can tell you that "i" will put you back into input mode from command mode.

You string those all together, you get:

--------------------

for () {^[o}^]keei

--------------------

You may have noticed that using "e" to go to the end of "if" in the last example was unnecessary and could have been done by moving right one instead with "l". Well, that is true for "if" because it is a two-letter word. Examine the macros I use for for and while and notice how they can be almost identical because of the usage of "e" instead of simple direction keys. In fact, now is a good time to take a good look over those and notice the similarities.

Once you are satisfied with what you see (and maybe even comfortable, but that may be aiming too high), we'll proceed to the final exercise which is simply analyzing that last macro (a trivial process now that we just did a more difficult one.

The last macro reads:

--------------------

map!    ]inc    #include <.h>^[hhi

--------------------

Any C programmer would notice right away that that looks a lot like an #include line for inclusion of a header file, but it's missing a name. Well, the rationale behind this one is similar to the one I used in justifying the whole skeleton file idea. Basically, every #include'd file follows the same format, only varying in one tiny bit (the part of the filename before the .h). So, instead of typing stuff like this:

-------------------

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <sys/wait.h>
#include <unistd.h>

------------------
(this is an actual set of #includes from a small sockets program)

I just wrote a macro that will print out

------------------

#include <.h>

------------------

and then put me in input mode before the ".h", with a construct like that in place, writing all the includes is a trivial process that becomes much faster.

Let's analyze what we need to do. First, we need to output what is shown above, and then we need to simply position the cursor on the period and go back into input mode. Like I said, after what we just did, this is pretty trivial.

The first part is easy, it's just the text ("#include <.h>"). Next we escape out of insert mode so we can move the cursor ("^[", our cursor is now on the ">"). Then, we move it on top of the "." by moving it left twice ("hh"). And, finally, we put ourselves back into input mode ("i"). And <begin cheerleader voice> What's that spell? </cheerleader>

"#include <.h>^[hhi" !!!

Excellent! You now have a few more tools in your vim toolbox to get you started on customizing vim to your needs. For more info, read the online help or just experiment. There is a ton of other stuff you can do, but this is enough to keep you (and me) busy enough for a while. Enjoy!