gvim
After the last section about vim and how I pretty much only use it for mail related tasks, I'm sure some people have read it and thought to themselves "what a complete waste of a vim install." I'm tempted to agree, but vim is incredibly powerful and useful that I'm happy to have a command line version installed purely for writing mail. Today, I'm going to talk about vim again but today it is gvim. gvim, or GUI vim, means GTK in my mind. I'm not going to get in to all the reasons but suffice to say I'm a big GTK fan.
I'm going to skip vim's builtin features, infact I'm going to skip the builtin features in nearly every editor I discuss because each one shouldn't really need any explanation. Most of the editor's websites can tell you about the range of features they support, and in some cases they will also help you to find new plugins and support tools for the editors too. The normal rule of thumb applies here, RTF M and Website.
I want to start with a back reference to last section, everything I said about vim is equally applicable to the GUI version of vim. You could in theory edit your mail with gvim, I don't personally believe it would be all that practical but the choice is yours.
Note
Using gvim as a mail editor could possibly be considered practical if you always have gvim open and used it in conjection with the client-server mode. For more information read the help by issuing the command :help clientserver from within vim. If you decide this route might suit you make sure you take special notice of the --remote-wait option text.
Another thing worth mentioning is in my case it isn't all that unusual for me to combine the mail method I was talking about with text-mode vim with other plugins whilst using gvim, for example firing off diary entries from the vim calendar script straight at somebody. If you receive one of these it tends to mean you are behind schedule, and should be expecting a phone call in about an hour if the problem hasn't been rectified ;)
Note
If anybody is interested in ways to simplify the calendar integration drop me a mail, and I will write about the heap of functions/mappings that I use for this and a few other mail related tasks. So I suppose that is as good a place as any to start properly; the calendar plugin.
Note
Before I get yet another mail about it, the clock in the bottom right hand corner of the screenshot is provided by xdaliclock.
The calendar plugin for vim is perfect for people like me who spend all day with their editor open, it saves yet another application being open just to remember what tasks have been thrust on you from upon high. The calendar plugin, which can be accessed with :Calendar once installed, not only shows you a calendar that you can navigate through but allows you to add entries for specific dates by double clicking on the date.
The format for calendar entries is simple, and very workable from external tools should the need arise. Entries are stored in a directory, ~/diary by default but you can change it by setting the calendar_diary variable, which contains subdirectories for year then month then files named $day_number.cal. The format is a simple text file, no markup is needed.
The fact the data storage is so abstracted allows you to use the data for other purposes too. For example, to build a HTML file containing your calendar or perhaps even an RDF format vcal file.
Note
If you want to see how I build such files with the vim calendar data drop me a mail.
Another plugin that is shown in the screenshot above is taglist on the right of the screen. It provides a small window that allows you to navigate your buffers using an Exuberant Ctags generated index of functions/defines/etc. The fact it uses Exuberant Ctags means it supports an insane number of file formats out of the box, and allows you to add support for your own filetype with the absolute minimum of effort.
Note
Be aware that the taglist plugin does not use the normal TAGS, it dynamically generates the tags by running the ctags command for every opened file. So it won't pick up any new filetypes you defined when creating the TAGS file. You need to add your extra options to your ~/.ctags or possibly even your /etc/ctags.conf file.
The plugin shouldn't need much explanation, and if it does a really good helpfile is installed with the plugin. All you should need to know is a simple click(actually a double click by default) will take you to the section which contains the function/macro/etc under the mouse.
Note
There is also a tagmenu plugin available at the vim website which provides the same sort of functionality in a dynamically updating menu instead of a window. I imagine some people who use small workspaces for their toplevel vim window will find it more comfortable. Either way one, or even perhaps both, are essential for editing source code in my opinion.
At the top of the screenshot is one of my favourite plugins minibufexpl which provides a mini menu of all open buffers you can click on to quickly switch between files. Think of it as a file based taglist. By default it opens when more than one buffer is open, so it doesn't even waste screen space when you are just doing a quick one file edit. It also comes with fantastic documentation, so install the plugin and look at the customisations it offers.
If you edit a lot of XML, like I seem to do lately, Devin Weaver's XML filetype plugin is an excellent enhancement to vim. It makes vim write closing tags automatically, for example typing <mytag> will cause vim to write out <mytag></mytag> and place the cursor right after the opening tag. If you press '>` twice to close the tag it will place the cursor on the following line and the closing tag on the line after that(an amazingly simple method to keep a nicely indented XML file in shape). The plugin is clever enough to recognise non-container tags, such as <br />, and will not add an extra and obviously broken closing tag.
I suggest you read the plugin's documentation if you need to edit HTML or tagsoup with the plugin, as it provides some functionality that may help you even if you haven't yet seen the light and moved to XHTML. In fact I recommend you read the documentation in any case, because it will point out a few bugs it has and also show you some of the other the cool features it has(semi automatic tag deletion being my favourite).
My final plugin I want to talk about is vimoutliner, another one of my favourite "plugins" for vim which provides a fantastic outline mode for vim. I've opted for quoting the word plugin here because vimoutliner is so much more than a simple plugin in my eyes, and calling it such doesn't quite do it justice. I would make one comment, and that is be very careful using the supplied automatic installation script it is a little iffy at best and mayhem creating at worst.
Note
If you are used to the emacs outline mode I would hold on to your hat, vimoutliner provides some really good features not available in the the outline mode in emacs. There is a reason why vimoutliner ships with 40 kB of documentation, so read it ;)
The vimoutliner packages provides a simple way to manage outlines for anything you can represent with a hierachy. It features some really good options like checkboxes to show completed tasks, and an automatically updating progress status through the use of a percentage complete display. Thanks to the wonderful folding available from vim, you can also hide entire sections of the outline file to concentrate on the contents of specific branches.