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!
