There's an option which allows you to make the undo history persistent between Vim sessions. That means you can still undo changes you made in a file, even if you've quit Vim in the meantime.

You can add the following to your .vimrc to enable it:

set undofile   # Maintain undo history between sessions

This will create undo files all over the place, which look like this:

-rw-r--r-- 1 fboender fboender 320 2012-07-26 10:23 bad_gateway.txt
-rw-r--r-- 1 fboender fboender 523 2012-07-24 14:51 .bad_gateway.txt.un~

You can remedy this by including the following option in your configuration:

set undodir=~/.vim/undodir

Make sure to create the undodir:

$ mkdir ~/.vim/undodir

The undo files will now be saved in the undodir:

$ ls -la .vim/undodir/
total 12
drwxr-xr-x  2 fboender fboender 4096 2012-07-26 10:32 .
drwxr-xr-x 12 fboender fboender 4096 2012-07-26 10:24 ..
-rw-r--r--  1 fboender fboender  519 2012-07-26 10:32 %home%fboender%bad_gateway.txt

As a kind of work-around, I created Bexec, which allows you to run the current contents of a buffer through an external program. It then captures the output and inserts/appends it to another buffer.

Although Bexec works reasonable, and still has it's uses, it's not a true terminal emulator in Vim. Today I finally found a Vim plugin that let's you actually run interactive commands / terminals in Vim buffers: Conque.

It requires Vim with Python support built in. Installation is straight-forward if you've got the requirements.

Download the .vmb file, edit it in vim, and issue:

:so %

It will then be installed. Quit vim, restart it, and you can now run start using it:

:ConqueTerm bash

Very awesome.

Here's my favourite list of tips:

Add the following text to your ~/.vim/ftplugin/php.vim file:

set formatoptions+=tcqlro
let php_sql_query=1
let php_htmlInStrings=1
let php_folding = 1

This will:

• Turn on automatic text formatting for PHP so that, for instance, Vim automatically inserts a '*' if you press enter inside a /* */ comment.
• Makes Vim highlight SQL queries in strings.
• Makes VIm highlight HTML in strings.
• Allows folding on PHP classes and functions. (With the cursor on the first line of a function, press z-c to hide the function. z-o to show it again. (Close and Open the fold)

Edit your .vimrc and add the following lines:

if has("autocmd")
  augroup php
    autocmd BufRead *.inc set filetype=php
  augroup END
endif

This will make Vim recognise .inc files as PHP files and treat them accordingly (syntax highlighting and whatever else you've set Vim up to do with PHP files).

Security note: It's not a good idea to name files that will be included '.inc'. Bad configuration of your webserver may make the source of those file available unparsed through your webserver. Either name them .inc.php, or don't place them in a dir under your webroot.

Ctags is a great utility. It creates a file with a list of 'tags' that are found in various program sources that it finds in the directory where you run it. These tags can then be read by editors so that they know where in the source to find, for instance, the definitions of functions, methods, constants and variables. Or as the CTags homepage describes it:

Ctags generates an index (or tag) file of language objects found in source files that allows these items to be quickly and easily located by a text editor or other utility. A tag signifies a language object for which an index entry is available (or, alternatively, the index entry created for that object).
Editors like Vim use it to let you peek at or jump to the definition of a function; a feature commonly thought to only exist in bloated IDE's such as Eclipse.

PHP5 Object Oriented

Unfortunately, CTags doesn't support PHP's Object Oriented features very well. All you'll get is globally defined constants and functions. It also generates tags for classes, but that's it. No support for methods or anything! Hardly very useful in it's current form, I'd say. Thankfully there is a patch available that greatly extends CTags' Object Oriented PHP support.

Fixing CTags

To fix CTags so that it does support PHP in a not-completely-retarded fashion, you'll have to patch and compile CTags yourself. Here's how:

Download CTags v5.5.4.
Download the patch (alternatively and in case the patch disappears from the previous location, download it from electricmonk's mirror.

Next, patch, build and install CTags:

[todsah@jib]~/download$ tar -vxzf ctags-5.5.4.tar.gz
[todsah@jib]~/download$ patch ctags-5.5.4/php.c ctags-php5.patch
[todsah@jib]~/download$ cd ctags-5.5.4
[todsah@jib]~/download/ctags-5.5.4$ ./configure
[todsah@jib]~/download/ctags-5.5.4$ make
[todsah@jib]~/download/ctags-5.5.4$ sudo make install

The new ctags binary will be installed in /usr/local/bin by default.

Now you can use the self-built version of ctags to create tag files that contain enough information about your PHP's source code to actually do something meaningful:

[todsah@jib]~/plugwiki$ /usr/local/bin/ctags -R --extra=+q

Fire up your Vim editor (you are using Vim, aren't you?? Get off my site, you dirty Emacs user!) and start exploiting your newly created tags file.

Using ctags in Vim

In case you don't know how to use ctags from within Vim, don't worry. It's really easy. Move the cursor on top of some method call and press Ctrl-]. Vim will jump to the definition of the method/function/constant/whatever that the cursor was currently on. To jump back to where you came, press Ctrl-t. It's a simple as that.

An example. Suppose I have the following code:

if (!$page->hasAccess(

I'll position my cursor on hasAccess and press Ctrl-]. Vim will now jump to this text:

  public function hasAccess($user, $access)
  {
    $userId = $user->getUserId();

When I type Ctrl-t, Vim will jump back to:

if (!$page->hasAccess(

and I can complete my code.

Another cool tool for Vim that uses tags is TagList.

The "Tag List" plugin is a source code browser plugin for Vim and provides an overview of the structure of source code files and allows you to efficiently browse through source code files for different programming languages.
You can see TagList in action in this screenshot of Vim.

^{(Thanks to Michiel van Baak for corrections in this post.)}

So I tweaked the vimrc settings to make Vim under windows as much the same as GVim for Linux as possible. I've put the resulting _vimrc online.

I also did some updates on the white.vim colorscheme.

:e ftp://[user]@[hostname]/file

But that didn't work for me. I thought I tried everything, but it just wouldn't work. Some red-coloured errors flashed by everytime I tried to open a FTP file, but I coulnd't read the errors because they were gone too fast.

Turns out I had to make sure of at least the following:

• Don't forget to create a temporary directory c:temp or c:tmp, or some other path which is set in the 'directory' setting in vim (type ":set directory" to find out). GVim needs it to temporary store the file there.
• Make sure the NetRW plugin is loaded.
• When opening a FTP file, make sure you put a DOUBLE SLASH between the hostname and any filenames. For instance, I tried opening the file ftp://hostname/myfile.php, and it worked. But when I tried to open ftp://hostname/mydir/myfile.php, it failed! When I entered ftp://hostname//mydir/myfile.php, it worked again. Weird stuff but who cares? As long as it works, it's all fine with me.

I've got some more tips and pointers about the windows version of GVim. One of them is: "Don't use windows." ;-) Some other tips might be added to my vim page in the near future (where 'near future' in my dictionary is defined as 'somewhere between now and a vague and distant future).

Why is that a Good Thing? Because programmers are lazy. Now, usually that's a good thing. A lazy programmer is a good programmer because they don't want to do stuff twice. This forces them to create all kinds of neat stuff which they can re-use later on. On the other side, being a lazy programmer is a Bad Thing. Some programmers don't want to think about design or underlaying structure of programs. They just want something that works.

So, what does that have to do with RAD (Rapid Application Developement) tools? A lot. Today's RAD tools like Java Builder or Visual .NET allow you to click around a bit and put together a nice interface. Then you double click some button and add some code to load some things into some list somewhere. Double click another button and make it write the information in the list to a file. You're happily clicking all over the place, adding some code here and some code there, but you've missed a very important thing. You're mixing the logic of your program with the interface! In expensive manager-speak: You're mixing Business Logic with Presentation Logic. Ouch, that's a very bad thing.

One of the most important (and incidentelly one of the least tought lesson in IT educations) leasons in programming is: Low coupling! What?! Low coupling! Let me explain by quoting my favorite piece of programming-related writing, The TAO of programming:

"A program should be light and agile, its subroutines connected like a string of pearls." — TAO of programming.

The pearls are your Business Logic. The string is the interface. It's as simple as that. One pearl for loading a list of data, one pearl for the list (not the list you see on-screen but the list in memory) itself, one pearl for saving, etc. The user interface is the string which connects the pearls. From the load button, which calls the load pearl to the list you see on-screen which calls the list pearl.

Suppose you've mixed the business logic of saving the list into the save button. What if you want to extend your program so it can be controlled remotely via the network? You would have to move the logic of saving the list to a seperate function and have the save button and the remote save method both call that function. In the end, you are still decoupling your user interface and business logic. So why not start out with low coupling in the first place?

Of course it's perfectelly possible to write low coupled applications in Rapid Application Development tools, but they make it sooo easy too just add the business logic into the user interface. I once said to a proffesional programmer: "Then you add a function there to do this and that" and he replied: "Uhm, where's the button for adding a function?". Excuse me?

Most good open source developers know about low coupling. They also know about the power of the current tools for developing programs under Unix. They know that NO RAD tool can beat the development power of Vim or Emacs or some other advanced editor. Want to compile stuff from your editor? Vim does that. Debugging? Vim does that too. Advanced Unix editors do all of the stuff an 'IDE' can do and much much more. Except for designing an interfacei by dragging buttons onto some window. And that's just the way most developers like it. That's probably why there aren't any RAD tools for Linux like there are for Windows.

And besides; coding your interface from scratch isn't that hard to do at all. And because you have to actually assemble the interface yourself, you get a much better understanding of the underlaying code. Extending your program will become easier and faster. No more copy-pasting of code from all over the place and ending up with the same piece of code in four places all over your program.