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 NHF 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---

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:::

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

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

[- Next Page -]