It Feels Like ~

Command Line Bookmarks

2008-04-03T19:31:00.001-05:00

I wish I'd known about this tool years ago. Today I discovered a little utility called cdargs. Basically it lets you browse your directory tree very quickly, and allows you to create bookmarks to your most often used directories.

The bookmarks are stored at ~.cdargs in a simple format that's easily edited whenever you want to modify them, but I'm getting ahead of myself now...

cdargs has a directory browsing tool which is invoked by the cv command. In this tool, you can use arrow keys, Vim bindings, or even Emac bindings to navigate. Pressing a on a directory in the browser adds it as a bookmark, and pressing Enter opens it back in the shell. To see more of the available commands, press H or ? in the browser.

Outside, back in the shell, you can copy files and move files to your bookmarked directories using the cpb and mvb commands respectively. For example, cpb foo bar will move the file called foo from the current directory to the directory that I have bookmarked as bar. You guessed it, cdb bar would change you to the directory bookmarked by bar as well.

This tool has several more features as well, but I'll leave those up to you to discover. The man page is a good read, and I don't want to take all the fun away from you :). The only problem I can see with this tool is that it may be difficult getting used to the different commands. Typically the commands they replace or supplement are used quite quickly. By the time I stop to recall the applicable cdargs command I've waited too long. If I can get past that, there's no doubt I'll get some good use out of this one.

Change the Solaris Shell to Bash

2008-03-15T11:03:00.001-05:00

For those of us that are stuck working in Solaris environments with either csh or ksh as the default shell, there is hope. Some of these environments have the chsh command to change shells, but for those that don't, here is how to change your shell to bash. First of all, make sure it is available on your system. It's typically found in /bin/bash. If it's there, you can edit your ~/.profile to make it run the new shell when you login.

IMPORTANT: Before doing this, open two separate shells. Keeping one open and unaltered is a good way to recover if something goes wrong in this process. If you break something and can't log in, you may piss off your system admin when you have to call him to fix it for you. Leave one of these open shells alone during this process.

In one of your open shells, add the following two lines to the bottom of your ~/.profile.

export SHELL=/bin/bash
exec $SHELL

You can now log out of that shell and back in again to see if it worked. If so, all went well and you can close the other shell. If not, use your "safety" shell to repair your ~/.profile so that you can log in again.

Google Makes Me Stupid

2008-02-24T14:27:00.001-05:00

Does anyone else find that sometimes their first response to a problem is to search Google? I just had the good ol' 500 Internal Server Error in an Apache request and immediately I searched Google for assistance. Given that the web server in question was my own, the reasonable person would first check the server error.log, but I'm apparently not that guy. In my defence, it didn't take long for me to remember this, but still, Google was my initial reaction.

A quick check of said log file suggested an .htaccess issue, and now all is well. Perhaps we're (I'm?) becoming too dependant on our search engine overlords...

Vim and Perforce

2008-02-24T14:14:00.001-05:00

My employer has used Perforce as a VCS for several years now. Perforce itself maintains integration plugins for Eclipse, but of course not for editors like Vim so it's up to the community to do so. Lucky for me, extremely capable Vim scripters like Hari Krishna Dara also use Perforce from time to time :). This is the same author who brought us the genutils.vim plugin as well as many other powerful scripts as his vim profile lists. Among these is a fantastic perforce script set that I downloaded to try about a week ago. It was more than I'd hoped for.

This is a very featureful Perforce integration script with a complete set of menus (although I have menus hidden in my vim) and commands. I'm not sure whether the author still uses it or not however because there was a bug in spec-based commands that broke it pretty badly. Of course, there is the possibility that I'm using it incorrectly too. Regardless, I've "fixed" a couple of these bugs and emailed the author with a patch. I also uncovered a bug in the genutils.vim script that it depends on. The author also mentions this in the script page for the Perforce plugin:

--------------------------------------------------------------------------------
Lately, I am not finding enough time to add features to this, so if anybody is
interested to help me add new features or even take over the responsibility, you
are very much welcome.
--------------------------------------------------------------------------------

Although I sent him a small patch in his Inbox, he may not have the time to make a bug fix release, so I've made a little bazaar branch of the complete script on my own little server here for the time being. This branch includes the fixes for a couple of little bugs, and some extra syntax hinting for pending changelists and closed jobs. Aside from that, it's unaltered. You can get it using this command, assuming you have bzr installed.

$ bzr branch http://arker.homelinux.org/~dcraven/bazaar/vim-perforce vim-perforce

I might add a few features or commands that have been included in the p4 client since his last release of the script at some point too. Depending on his email reply (if he replies) we'll see if he'd like my changes included in his next release or not. My additions unfortunately won't be of the same quality as the stuff he's already written. I'm not exactly a seasoned vim-scriptor...

All in all, it's a fantastic script. Check it out if you use Vim with the Perforce VCS, and big kudos and thanks go out to the original author!

Stumped by a Captcha

2008-02-19T20:07:00.001-05:00

Does anyone see the security code in this captcha?

This one has me stumped...

GnuCash Broke My Ledger :(

2008-02-18T22:06:00.001-05:00

For the past year and a bit, I've been happily using GnuCash with Ledger and it had been a fantastic duo. Several days ago, I upgraded to GnuCash 2.2.3 and the combo doesn't work so well anymore. The problem stems from an internal change that adds a "Root Account" as the top level account in the tree. To say the two don't work together anymore might be a little harsh, but they at least don't work as well together as they used to. For example, this used to work to get a quick net worth:

$ ledger bal ^ass ^liab

The ^ass and ^liab bits are regular expressions that match all accounts that start with the letters ass and liab (assets and liabilities) respectively. This would result in a little chart showing my total assets minus my total liabilities, since "Assets" and "Liabilities" used to be top level accounts. Now with the new structure, these accounts are no longer roots. Instead they look like "Root Account:Assets" and "Root Account:Liabilites". Long story short, this new "Root Account" is the only top level account. To make matters worse, the bloody account name has a space in its name, and we all know how well spaces work on the command line...

Needless to say, the combination became a lot less useful with this update. I'm not sure whether to downgrade to GnuCash 2.0 or not. What a shame.

Changing the Default Text Editor in GNOME

2008-02-16T18:03:00.001-05:00

The "Preferred Applications" menu item in GNOME runs a little app that allows you to change some of the default programs used for various tasks like web browsing, music playing etc. One thing that's been missing for me is the ability to change the default text editor. Sure you can open up Nautilus, right click on a text file, and chose that way, but there are many types of text files, and they are each treated independantly.

Recently I discovered the ~/.local/** path. I'll use gvim as an example for this excersise. This is the ticket for swapping default editors once and for all! First, use the method described above (the right click in Nautilus way). Now you should have a ~/.local/share/applications/gvim.desktop file. That's good. Next, create a ~/.local/share/applications/defaults.list file, and put this in it:

    [Default Applications]
    text/plain=gvim.desktop
    application/x-perl=gvim.desktop
    text/x-chdr=gvim.desktop
    text/x-csrc=gvim.desktop
    text/x-dtd=gvim.desktop
    text/x-java=gvim.desktop
    text/mathml=gvim.desktop
    text/x-python=gvim.desktop
    text/x-sql=gvim.desktop

The contents above were taken from my own system wide /usr/share/applications/defaults.list, just with :%s/gedit/gvim/. This should at least cover the file types that gedit keeps popping open for. You could always modify the system wide defaults.list, but be prepared to lose those changes during your next update. Also, since the gvim.desktop file already existed in my local home path, I never tried just copying the one from /usr/share/applications. That might work too.

I can't believe I've been using GNOME for so long and never knew this :(

Tiny Tiny RSS Feed Reader

2008-02-16T17:13:00.001-05:00

Lately, I've been missing something in a feed reader. In the past six months or so I've tried a plethora of different readers of different forms. I tried the desktop application style like Lifrea, the online flavors like Google Reader, and the Firefox extension kind like Sage. All have their benefits, but also disadvantages. For example offline readers make it a pain when one uses different machines, online reader services felt slow or sluggish, and cluttered. Not to mention they can't be modified.

I forget now how I heard about Tiny Tiny RSS now, but if I remember I'll update this post with well deserved props. This thing is perfect in my opinion. It's fast, it's open source, it's written in PHP/MySQL, and it's pretty feature complete. Even setup was a breeze and went without a hitch.

The interface is very clean and well organized. One can tell pretty early that some of the interface ideas in TTRSS were inspired by Google's great GMail interface like the ability to star articles as well as the familiar actions list, and in fact it very much has the feel of using your typical desktop email application. This reader can run in either single or multi-user modes, and you can publish your feeds and articles with others with a single click.

I'll not provide a list of features here since they do a pretty good job of that on their website. If you are not in love with your current reader, I very strongly suggest this gem!

It's Been Almost a Year

2008-01-20T16:16:00.001-05:00

I'm about as interested in writing a reasons-for-not-posting-for-a-year blog entry as you are in reading one. Instead, I'll just say that since my last post I've gotten a job and I've gotten my wife pregnant.

The baby is due in May!

P.S. I really should take that terrible picture of my head down from up there...

Beryl and the ATI IGP 340M

2007-01-24T16:33:00.001-05:00

I can't believe nobody told my that Beryl would work with my cruddy 340M graphics chip. I threw caution to the wind today and tried it only to find out that it worked quite nicely! Sure, it's not as smooth as on my desktop machine with an NVidia chip, but it is very usable and pretty. I basically just followed these instructions and boom. All was well. Oh, I also changed the driver in my /etc/X11/xorg.conf file to radeon from ati.

Anyways, here is the cool screenshot...

Rotating Backups with Rsync

2007-01-04T14:30:00.001-05:00

The Christmas break was pretty good, with one exception. The hard drive on my laptop gave me some serious grief. Long story short, I wiped it, made new partitions, and reinstalled the OS. Now luckily, I was smart enough to keep partial daily backups on my server for just these occasions so nothing too important was lost (thesis). However, the keywords here are partial backups. This means that most of my settings and non-crucial data was not backed up, and that has turned out to be a bit of a drag.

Anyways, the hard drive appears to be functioning correctly now, I purchased an el cheapo (some of us never learn) external drive, and I'm looking to do full backups of my $HOME directory from now on. A quick search took me to the concepts outlined here. This scheme is pretty clever, is suprisingly fast, and very efficient on drive space. The result is a simple Python script that seems to do the trick. Well, it's mostly Python with a bunch of Bash calls via os.system(), but close enough.

Basically, it uses rsync to synchronize data over an ssh connection to my remote server. That remote machine has the external drive attached and mounted. Given a remote destination directory, it creates a series of backup directories based on the local machine's hostname. For example, my laptop's hostname is sigma and the script creates the directories sigma/sigma, sigma/sigma.1, sigma/sigma.2 etcetera all the way up to sigma/sigma.7. These numbered directories contain snapshots of the data back seven runs. So if you run the script once per day, you have a snapshot for the past seven days. Instead of storing all of the data seven times however, it uses hard links to save space. I'll let you read up on this concept here if you are interested.

Several assumptions are made in this script. One is that you have passwordless ssh logins setup correctly. Also, the script requires a configuration file called ~/.backuprc where several custom settings are stored and read. Here is an example of such a file.

EXCLUDES = *.iso,*.avi,*.mpg,*.mp3,*.ogg,*.wma,*.wmv,*.mov,*.LNK,*.LCK
SOURCES = ~/
DEST_HOST = arker.homelinux.org
LOG_DIR = ~/.backup_logs/
DEST_PATH = /media/backup_drive/home_backup/

The variables in this file break down as follows...

EXCLUDES: A comma separated list of patterns matching files that are not to be backed up.
SOURCES: A comma separated list of directories to be backed up. The example instructs the script to back up the user's entire home directory.
DEST_HOST: The host of the remote server where the backups will be sent.
LOG_DIR: The location where log files should be saved.
DEST_PATH: The destination on the remote machine where the backups will be stored.

I put an entry in my user's crontab to run the script at 12:05pm every day. The entry looks like this:

5 12 * * * /home/dcraven/bin/backup

The script is located in my ~/bin directory. If you need help with cron, have a look at this tutorial. Keep in mind that when run this way, cron will only execute the command if the machine is on when it is scheduled. It will not automatically run when the machine is started when a scheduled time is missed. For this behaviour, look into /etc/cron.daily and friends.

At the moment, all of these settings are required in the file. At some point I might write something a little more robust and clean, but for now this works and I have other things that should be given a higher priority.

Searchable Tags in td

2006-12-20T14:49:00.001-05:00

I'm starting to really like writing console apps in Python. To add a feature takes no time at all since there is little UI to deal with. Over the last hour I've implemented tagging for your tasks in td. Tags for searching and grouping items seem to be pretty popular in current applications, so I thought why not a todo list manager? I think I like this better than the projects I implemented a couple of weeks ago. The projects stuff is of course still available and fully functional, I just don't think I'll be using it as much anymore because the new tags are much handier. In fact, you can still use both at the same time. Here is how the new tags command works...

When you create a new task, a group of tags can be associated with it by including a space separated list, enclosed in square brackets, in the task summary.

$ td add [tag1 tag2 tag3]This is a new task.

Now, if I want to see what tags are being used:

$ td tags
--> Available tags:
--> tag1(1) tag2(1) tag3(1)

Issuing the new tags command with no arguments lists all tags, and the number of tasks with that tag. If you want to see a list of tasks by tag:

$ td tags tag1
-->  #   P H  Created    Description
-->  1        12/20/06   This is a new task.

Maybe you want to see a list of tags that are associated with a specific task?

$ td tags 1
--> [tag1 tag2 tag3]

Want to remove the "tag2" tag from that task? No problem...

$ td tags 1 -tag2
$ td tags 1
--> [tag1 tag3]

Let's remove "tag3" now, and add "newtag" to this task:

$ td tags 1 -tag3 +newtag
$ td tags 1
--> [tag1 newtag]

You can still use the replace command to replace all of them at once.

$ td replace 1 [foo bar]This is a new task.
$ td tags 1
--> [foo bar]

And of course you can easily combine hidden status, tags, and projects all at once.

$ td add .[tag1 tag2] p:MyProject This is yet another new task.
$ td tags tag1
-->  #   P H  Created    Description
-->  2     *  12/20/06   This is yet another new task.
$ td project MyProject
-->  #   P H  Created    Description
-->  2     *  12/20/06   This is yet another new task.

Notice the "H" column in that output indicates whether the task in the list is hidden or not. That column was recently added to both the tags and the project output. These changes are committed and pushed to the bazaar repository that I spoke of in my last post. Don't forget to email me the bugs!

Now Using Bazaar for a VCS

2006-12-20T13:58:00.001-05:00

In order to hang with the cool crowd, I've decided to fall for the hype and jump ship (at least for now) to a distributed version control system. The one I've chosen is bazaar, mostly because it's written purely in Python. I like playing with new things from time to time, and bazaar commands are a pretty smooth transition from their Subversion equivalents.

So, in order to get the latest and greatest unreleased code for td or vim-blogger, you can use bazaar and grab the source from here and here respectively.

If need a quick learning reference, have a look at the bazaar tutorial. It seems the User Manual link on the website points to the tutorial as well.. Hmm. To find out more about the program, the official website can be found here.

Vim-BloggerBeta Plugin Release

2006-12-19T14:18:00.001-05:00

It turns out I'm not really doing any more modifications to this plugin code because it is working fine for me. I decided then, instead of just sitting on it maybe I should share it! So here it is... Keep in mind that this no doubt a little rough around the edges as far as usability goes. I'll do my best to describe the plugin here.

Pre-requisites

First of all, this plugin requires Python support to be compiled into Vim. As in, if you do a :version in Vim and do not see +python in the output, this plugin will not work.

Also, you will need to provide some information for the plugin in the form of three variable settings. The plugin needs to know your blog URL, your Gmail login, and your Gmail password. The variable names for these are g:Blog_URI, g:Gmail_Account, and g:Gmail_Password respectively. Given that some of these variables contain sensitive information, you probably want to take some steps to keep them somewhat private. I often put my ~/.vimrc online for others to read, so putting them in there is a bad idea. Instead, I created a ~/vim/plugin/creds.vim file, made it readable by my user only, and stuck the info in there. Keep in mind, however, that these are global variables and as such, will be available to all scripts that you run. Also, someone could quite easily get those values by typing :echo g:Gmail_Password in your vim session for example. If you have some ideas about how to keep this stuff more secure I'd be interested in hearing about them. For now, however, you've been warned :).

Installation

The plugin comes in the form of a tarball. Inside this tarball are five files.

plugin/blogger.vim: This script provides a single command called :Blog that simply opens a temporary blogger file which in turn sources the blogger.vim filetype plugin.
ftplugin/blogger/blogger.vim: This is the filetype plugin that contains the rest of the plugin's functionality.
syntax/blogger.vim: The included syntax file provides highlighting to buffers with the filetype blogger. It is essentially the Markdown syntax file found here with a few vim-blogger specific additions.
ftplugin/blogger/markdown.py: This is the Python module found here that the plugin uses to convert Markdown to HTML.
ftplugin/blogger/html2text.py: The Python module found here which the plugin uses to convert HTML back to Markdown.

To install, you just need to untar this tarball inside your ~/.vim/ directory. All should fall into the appropriate locations. Next, you probably want to make Vim set the filetype to blogger whenever it opens an appropriate file. To do this, put this line in your ~/.vim/filetype.vim file:

autocmd! BufRead,BufNewFile     *.blogger   setf blogger

This will set the filetype accordingly whenever you open a file with the blogger extension, hence sourcing the ftplugin and syntax files.

General Post Form

In a Vim buffer, a post generally looks like this screenshot:

The first line in the buffer is the post subject. The last line contains the keyword @@LABELS@@ followed by a comma separated list of labels for this post. The stuff in the middle is the post body. One variation of this is if you are editing a post that was already published. In this case, the first line will be of the form @@EDIT#@@. This is put there by the plugin, and used by the plugin. You probably don't want to delete it. In this case, the post subject will be the second line in the buffer.

Usage

There are several commands included with the plugin. I'll briefly describe each of them here.

Retrieving Your Most Recent Posts

Running the :BlogIndex command will display a list of your most recent blog posts. By default, it will only display the last five to keep the list manageable, but it can take an integer argument if you would like to change that. A numbered list of posts is shown. To begin editing one of these posts, simply type the post number and press Enter. This list also contains posts that you have saved as drafts. Drafts are distinguishable by the word **DRAFT** beside the post subject.

Retrieving Your Posts By Label

If you would like to see a list of blog posts by label, run the :BlogQuery command with a comma separated list of labels that you would like to query for. Again, a numbered list is returned. To edit a specific post, type the appropriate number and press Enter.

Publishing or Updating a Post

The :BlogPost command can be used to either publish a new post or to update an existing post. If the current post is marked as being a draft, then the draft status is removed and the post is published. Upon successfully issuing this command, it will appear in the list displayed by the :BlogIndex command.

Saving a Post as Draft

Just like the :BlogPost command described above, the :BlogDraft command sends your post to the Blogger server, only this time it is marked as a draft. The post will not appear in your blog, but will appear in the plugin's index (displayed with the :BlogIndex command) as a **DRAFT** post.

Deleting a Post

To delete a post, run the :BlogIndex command to get a list of posts, choose the post from the list as if you were going to edit it, and issue the :BlogDelete command. The plugin will ask the user for confirmation, and upon responding with "yes" (nothing else will do), the post is deleted from your blog.

Using or Not Using Markdown

One of the things I like about this plugin is that I can use Markdown syntax to write my posts. This text is then converted by the plugin to HTML, and sent to the Blogger servers as a post. If I then want to edit that same post, the HTML code is retrieved from the server, converted back to Markdown, and made available for me to edit. Some people, however, will inevitably prefer to just compose their posts in straight HTML. For these people, there is a global variable called g:Blog_Use_Markdown which enables this portion of the plugin. To reduce confusion for the people who do not know about this feature of the plugin I've made this variable default to False. Therefore, if you want to use the Markdown stuff, put let g:Blog_Use_Markdown = 1 in your ~/.vimrc file.

Conclusions

Keep in mind that this plugin was written to scratch a particular itch of mine that was caused by slow web interfaces with a cruddy editor in a slow web browser on a slow laptop. I've been using it to make all of the posts that you see on this blog. However, it may or may not do what you expect when you expect it. Hopefully there are few actual errors, but I'm sure there will be some as I've not fully tested the plugin under every scenario. If you do find a bug or need help getting it to work, email me at my Gmail account, username "dcraven". General comments are welcomed here on the blog.

Install Packages Available for td

2006-12-15T16:38:00.001-05:00

Jason has graciously created a Gentoo ebuild for td and made it available for download here. It looks like it even installs the td.vim file in the appropriate spot. Neato. Thanks for that!

This inspired me to make a deb file so that it's installable via apt on Ubuntu systems. The deb file for version 0.3 is available from here. I've only tested this deb by installing it once on my own system. I'm not a package building expert by any means though. Let me know if there are problems with it. Lintian doesn't seem to have any issues at all with it. There's a first.

Version 0.3 of td Released

2006-12-14T18:39:00.001-05:00

You thought this day would never come. The highly anticipated 0.3 release of the td command line task list manager is finally ready for public release! There have been a few fixes and additions to the feature list. I keep adding features here and there as I find things lacking during daily use. Here is a list of what's been added since I rolled the 0.2 tarball:

Support for 'hidden' tasks has been added.
Tasks can be grouped by and assigned to projects.
You can keep details or notes associated with your tasks.
Support for dark or light console backgrounds.
Choose between terse or more verbose "feedback" from commands.
Man pages are added for both td(1) itself, and the new tdrc(5) configuration file.

I think that's pretty much it. To be honest I can't really remember what was in 0.2 to begin with. The tarball can be downloaded from here, and the original post has been updated to reflect the new features.

Hopefully my server can handle the huge amounts of downloads expected over the next few days. If not, I may need to seek hosting elsewhere ;). If you have any bug reports or feature requests, please send them to me at my gmail address with username "dcraven". General comments can either be emailed to me or left in the comments section of this blog. Either way, they are appreciated.

td Gets Project Stuff

2006-12-07T12:19:00.001-05:00

Borrowing both the idea and the syntax from here, I have added similar project functionality to td. Now you can assign a task to a project by including a word in the description that is prefixed with 'p:'. For example, the following command will add a task to the "Office" project.

$ td add p:Office Phone that guy about the thing.

The difference between the implementation in td and the one at todotxt.com is that, in the above example, the task will appear in any displayed list as "Phone that guy about the thing.". That is, the "p:Office" part is removed. I think this keeps the descriptions a little cleaner.

Of course, this demanded an new command be added to the arsenal. That new command is proj. If the command td proj is given at the command-line, then a list of projects containing tasks is displayed. If however you provide a specific project like td proj Office, then a list of incomplete tasks belonging to that project is returned. The returned list is numbered as if a list of all incomplete tasks were requested, however, the tasks not belonging to the specified project are filtered out. To remove a task from a project, use the rep command, and exclude the prefixed word from the new description.

There is no tarball of td that includes this stuff just yet, so if you want to try it, you can check it out of the SVN repository located at http://arker.homelinux.org/td/ for now. Just like a good repository should, it also includes some glaring bugs that were found in the 0.2 tarball :).

UPDATE (Dec 14, 2006): I've started to use bazaar as a version control system for the td source code now. I've not used it before, so it sounded like fun. The bazaar branch can be found at http://arker.homelinux.org/~dcraven/bazaar/td/. I hope it works.

In the case where find a bug, or even have a feature request, email a bug report to me at dcraven at gmail dot com.

td - A Command-line Todo List Manager

2006-12-05T20:34:00.001-05:00

UPDATE: As of version 0.4, td depends on python-dateutils for date manipulation functions. Please make sure you have this installed prior to using td.

Introduction

Over a year ago, a friend of mine and I began tinkering with a little todo list program as we played with Python. We just wanted something simple and fast that could be used from the bash prompt without the fuss of a GUI. The result was a little script that we called td. For the past year, not much changed with it. I did a bit of work on it while learning how to use gnome-vfs, and added the ability to use remote data transparently. A couple of days ago, I began playing with it again. I added a few new and useful features, and decided to make it available to everyone in case somebody out there wanted such a tool. I'll outline the features of the program here.

Installation

The latest tarball of td can be downloaded from here, and is installable using the GNU autotools. In summary, navigate to the directory that has the downloaded tarball and type the following commands.

$ tar xvzf td-0.4.tar.gz
$ cd td-0.4/
$ ./configure
$ make
$ make install

You should now be able to run the program by typing td at the command line.

Features

The td script has the ability to add, delete, complete, prioritize, and archive tasks. This section will document each feature one at a time.

Displaying Tasks

Just running the command td with no arguments will display a list of outstanding tasks, sorted by descending priority. The output looks like this:

The output contains the item or task number, the priority of the task, the creation date, and the task summary itself. The task number shown in this list is useful for performing various other commands. The last line of output displays the number of shown tasks, and the number hidden (not shown).

Adding a New Task

The add command adds a new task to the list. For example:

$ td add Remind Jason to schedule his proposal.

This procedure is limited only by what is acceptable at the bash prompt. That is, things like quotes need to be escaped for example.

$ td add These \"quotes\" are escaped.

Deleting a Task

Deleting tasks can be done by specifying the task number to delete. For example,

$ td del 2

The above command will obviously delete task number 2 from the task list. Once deleted, tasks can no longer be accessed.

Deferring a Task

Sometimes you want to add a task to your list now, but don't want it to clutter up your task list until some date in the future. To do this, you would use the defer command. This command takes several types of parameters to determine the date to defer the task to. For example, the following command will defer task number 4 one week into the future.

$ td def 4 1w

Similar short forms exist for days (d), months (m), and years (y). The defer command also uses the python-dateutils to parse dates described by natural language. For example the following command will defer task number 4 to August 5th of this year:

$ td def 4 aug 5

If no further arguments are given to the defer command, a list of deferred tasks are displayed with their creation date, and the date they have been deferred to. Deferred tasks will not appear in the regular task list until their defer date is reached.

Undeferring a Task

If a task has been deferred to a future date, it can be made current again by using the undefer command. Obtain the task number by running td with the defer command without arguments. The following command will make the deferred task number 2 current again, hence making it display in the regular list of tasks.

$ td undef 2

Task Details

Some tasks require further details to clarify it further, or maybe just a place to store additional braindumps that you'd like to jot down. Details or notes can be added to a task using the details command. This command will cause your favourite editor to open, allowing you to type your notes. This additional data will be stored with the task data, and can be accessed by running the details command again on the same task. The following command can be used to added details to task number 4 in the list.

$ td details 4

Display Hidden Tasks

To display all incomplete tasks including the tasks marked hidden, use the hid command.

$ td hid

This will show all incomplete tasks in the list with an additional column marked "H". Each task that is marked hidden in the list will contain an asterisk in this column.

Prioritizing a Task

Prioritizing tasks can be done using the pri command. Entering the following command will assign task number 3 to the highest priority.

$ td pri 3 A

Priorities can be any single letter, and the display will be sorted by this key in descending order. Priorities of A, B, and C have distinct colours in the display output. Other priorities are just dark grey. By default, new tasks are given no priority at all. To remove the priority that was previously assigned to a task, run the same command, but exclude the priority.

$ td pri 3

This command will remove the priority from task 3.

Assigning Tasks to a Project

Tasks can be grouped into "projects" in td. To add a task to a specific project, you must include the project's name, prefixed with a "p:" somewhere in the tasks summary. The following command adds a task to the Office project.

$ td add p:Office Call Steve to schedule a meeting.

If you would like to see a list of projects that have outstanding tasks associated with them, you can use the proj command with no parameters. This will provide a comma separated list of projects. To display a list of tasks assigned to a specific project, run the same command with the project as an argument. This command displays all tasks under the Office project.

$ td proj Office

Already existing tasks may be added to a project using the rep (replace) command with the "p:" prefixed project in the new summary.

Assigning Tags to a Task

The td program supports "tagging" tasks with searchable tags. This can either be done when adding a new task, or after a task has already been created. To create a task with a set of tags, include the space separated tags in the task summary enclosed in square brackets. The following command creates a new task with the tags "work" and "python":

$ td add [work python]Script the emulator to run tests over night.

If you want to add tags to an already created task, you can use the tags command. To do this, append the tag with a '+' sign prepended to it. Removing tags from a task can be performed by appending a tag with a '-' sign. For example, the following command adds the tag "work", and removes the tag "python" from task number 5:

$ td tags 5 +work -python

To view a list of tags that have been assigned to any task, use the tags command with no arguments. This will display all tags as well as the number of tasks that have that tag assigned to them. Also, to see a list of tasks with a give tag or set of tags, use the tags command with the tags of interest as an argument. For example, the following command will display a list of incomplete tasks that have been tagged with "work" and "python":

$ td tags work python

To view a list of tasks that have no tags assigned to them, use the notag command with no arguments.

Completing a Task

Tasks can be marked as complete by issuing the do command. Once marked complete, tasks will no longer appear in the normal display list, and a completion date is assigned to them. The following command will mark task number 2 as being completed.

$ td do 2

Viewing Completed Tasks

As mentioned, once marked complete a task will no longer be listed in the normal task list display. To view all completed tasks, issue the done command like this:

$ td done

This will display a list containing a task number, creation date, completion date, and task summary. The displayed task number will be useful for performing various commands on completed tasks.

Marking Completed Tasks as Incomplete

If you have marked a task as complete by accident, or otherwise decide that a completed task should be reopened, you may issue the undo command.

$ td undo 2

The above command will mark the completed task number 2 as incomplete. The task number is the one displayed in the list provided by the done command. This task will now appear in the normal listing, and has no assigned completion date.

Replacing a Task

You may modify the summary of a given task by using the rep command. When given a task number, this simply replaces the summary of that task with the new one provided.

$ td rep 3 Fix a spelling mistake in this task.

Searching for Tasks

Tasks can be filtered by providing search patterns to the filt command. By giving a series of patterns, only those tasks who's summary match all patterns will be displayed. The resulting list will be numbered as if the full list was being displayed, but the tasks which do not match the patterns will be "filtered". This operation uses a smartcase search, which means if any of the given patterns contain at least one upper case letter, then the search will be case sensitive. If none of the letters in the pattern are upper case, then the search will be case insensitive. See the following examples.

$ td filt case insensitive
$ td filt cAse sEnsItiVe

The filt command can take as many patterns as you wish, in any order. Only the tasks matching all patterns will be displayed.

Archiving Tasks

Once completed, tasks may be archived in a text file in case you would like to keep them for future reference. The text file is stored in ~/.td/td_archive.txt. The file contains the summary, associated project, the creation date, and the completion date of all archived tasks. This operation permanently removes tasks from the todo list. You may archive a single task by providing its number, or all completed tasks by specifying all as an argument to the archive command. If no argument is given, td will ask you if you would like to archive all completed tasks. Answering "yes" will perform the archiving, anything else will abort. So basically, both of the following commands will work as expected.

$ td archive all
$ td archive 3

Purging Tasks

To just delete all completed tasks (unarchived) without saving them in the archive, issue the purge command. If given a task number, that task alone will be purged. If no task number is given, the user is asked for confirmation, and all complete tasks are purged.

$ td purge 3

This command will only purge task 3, without confirmation.

$ td purge

This command will prompt the user for confirmation, then purge all completed tasks. Purged tasks are lost, and cannot be recovered.

Getting Help

The td help command simply prints a message with a terse description of all the available commands, and their usage.

Specifying Your Data Source

This really only applies if you do not have gnome-vfs and its Python bindings installed. To set the data source after first run (see below), you can issue the source command. Doing this without the presence of gnome-vfs has no effect. However, you can change your data source to a remote file if you do have gnome-vfs installed. For example, the following command will make td use a remote file to store data over ssh.

$ td source sftp://your.host.com:/home/username/.td/todos.xml

From this point on you can use td as usual, and it will transparently use the data file stored at the given URI. The source command also takes the "local" argument (see below).

Without GNOME-VFS

If you do not have gnome-vfs and its Python bindings installed, the program will automatically store your todo list in the file ~/.td/todos.xml. There are no remote data capabilities without using gnome-vfs.

With GNOME-VFS

The presence of gnome-vfs and its Python bindings will be detected when the program is run. On first run, td will ask you to enter a data source. This basically just means that it needs to know where to store your data. If you enter "local" then your data will be stored locally in the file ~/.td/todos.xml. If you want to use remote data, enter any valid gnome-vfs URI to use that location. For example, the to use a data file stored in your home directory on a remote server, you could use sftp://your.host.com:/home/username/.td/todos.xml to make td use that data over ssh.

Types of Tasks

td maintains three types of tasks in its lists. This section will briefly describe each.

Incomplete Tasks

Incomplete tasks are basically any type of task that is not marked as complete. This is the default type when a task is created. These obviously represent tasks that are not yet completed, and which the user wants to appear in the default task list.

Hidden Tasks

These are a subset of incomplete tasks. They are treated the same, except the user doesn't want to see them in the default task list. Reasons for this may be to reduce clutter if for example the task is long term. Other reasons for marking a task as hidden are up to the user. Tasks are marked as hidden when, upon creation, the task summary provided begins with a period ("."), just like hidden files on the Unix file system. To mark a hidden task as no longer being hidden, use the replace command and enter a summary without the leading period. Similarly, to mark an already existing task as hidden, simply replace the current summary with one beginning with a period.

Completed Tasks

Tasks that have been marked as complete with the do command are no longer displayed in the default task list. To view these tasks, use the done command. To mark a completed task as incomplete, use the undo command. Only tasks marked as completed are available to the purge and archive commands.

The ~/.tdrc Configuration File

td now looks in $HOME/.tdrc if it exists for a few optionally configurable settings. This section will describe these settings.

The syntax used by the tdrc file is pretty typical for any configuration file. Entries are generally of the form {KEY} = {VALUE}. Pretty straightforward stuff. If the file doesn't exist, or only a subset of the options are specified in it, then sane defaults are chosen.

Background Colour

The background option informs td of the type of background on the user's xterm. If the xterm background is dark, then typically darker coloured text doesn't show up well. Setting this option to dark instructs td to use brighter colours for its output. Setting it to light instructs td to use more subtle colouring suitable for light backgrounds. The default value for this option is light.

Feedback Level

Sets the level of feedback that td should provide to the user. If the value of the feedback key is set to verbose, then positive feedback will be provided upon successful completion of commands. If set to terse then only errors will be displayed. The default value for this option is verbose.

Preferred Editor

The editor sets the preferred editor to be used when modifying the notes or details portion of a task. When deciding what editor to use, td will first check the $HOME/.tdrc file for a value. If none is set, then the value of $EDITOR is used. If still no value is found then Vim is used. This value can contain either a full path to the executable or just the executable file name provided it can be found in your $PATH. The default for this option is vim.

Extra Stuff

I like syntax colouring, and I use Vim for all of my editing. I made a very simple syntax file for editing td task details. It provides colours for the first line of the details file which indicates the project and the task summary. I also like to enter most of my notes in point form, so this syntax file also highlights lines beginning with an asterisk :). I know, I'm lame.

Anyways, this syntax file is available in the td tarball and will be installed into the $PREFIX/share/td/extras/ directory on your file system. To use it, copy it to $HOME/.vim/syntax/ and add the following line to your $HOME/.vim/filetype.vim file.

autocmd! BufRead,BufNewFile     *.td    setf td

After doing this, you should see the syntax highlighting the next time you run the details command in td.

Conclusion

If you decide to use td or at least try it out, you can probably expect a bug or two. If that is the case, or you need some clarification, feel free to email me so I can help. Although I don't expect there to be much demand for a tool like this one, if somebody besides me would find it useful, I'd like to make it work for them too.

Overreact Much?

2006-11-27T15:05:00.001-05:00

The recent kerfluffle over the post that Shuttleworth made on the openSUSE mailing list has me torn. First of all, and this is in no particular order, I think it's clear that Shuttleworth is just extending a friendly invitation to those developers that feel abandoned by the deal. That being said, however, it does serve his purpose to some extent as an email like this may poke said developer into action (ie. jumping ship) when otherwise he/she would have given into his passive ways and stayed where they were comfortable. Also, I think it is fairly well known that volunteer developers are typically welcomed, if not encouraged, to join any project they so desire. The fact that Ubuntu accepts new developers really isn't news. Whether the email was really composed as an innocent invitation, or as some kind of weird stunt, I guess we'll never know. And frankly, who cares?

On the other hand, I also think the openSUSE developers are overreacting a little in their responses. The most effective way to answer an unwelcome post like this is to not answer it at all. Being childish and bad mouthing competing distros is uncalled for, and that's exactly what some of those responses do. Swinging again in the other direction, however, what did Shuttleworth really expect? It's not difficult to predict that an email like this will be met with hostile resentment. It's not as though Gore invented the Internet just last week or anything. We've all see this stuff before, many times over. Someone (Shuttleworth) does something unacceptable, the victims (openSUSE devs) cry and toss insults back in response, then thousands of uninvolved peons (me) blog about it for weeks. Prodding people to leave the distro that they are clearly passionate about rarely ends nicely.

In my opinion Shuttleworth was silly to even think about making such a post to the mailing list. The guy is in no position to sing about unity and software freedom after making the decision to ship and install non-free binary drivers by default with the next Ubuntu release. I mean, let's face it. If I were an openSUSE developer who was looking to move elsewhere as a direct result of this deal, I'd make an attempt to decide which distro/company would least likely wind up doing the same thing to me in the future. If we lined up all of the major distros (Fedora, Debian, Mandriva, etc.) and looked at them in this light, I think many of us would agree which one we would add to the avoid list. The future of Ubuntu "freedom" spooks me a bit for some reason. I can't quite put my finger on the reason though.

I got a kick out of how this guy compares the Microvell deal and Ubuntu's commitment to freedom in a comment on the Newsforge article:

Microsoft+Novell deal involves: *Not sueing people.

Ubuntu involves: *Singing the praises of Free Software and all about how all software should be Free, yay, la la la, let's get around the bonfire and sing Koombayah and dress up the desktop in brown colors because it's all about humans and people and being human and proprietary software is bug #1 and...

*Except it actually isn't totally free software. Oops! We'll stick that in under bug #123581352.

*...But hey you SuSE goes can come develop for us cause we're more about Freedom and Unity with a capital F and U!

Not sure why, but I found that funny.

Replacing Mono Applications

2006-11-19T16:04:00.001-05:00

Since Novell admits to violating software patents in their code, and points at you and I for using offending software, I'm making an attempt to partially rid my machines of it. First to go, of course, is anything related to Mono. This means Banshee, F-Spot and Beagle need replacements. Replacing Banshee won't be a big deal in my case, since I don't really listen to music on my computer very often anyways. Also there must be a ton of music players out there. I think QuodLibet wins in this category for now just because it's written in Python.

F-Spot will be a little more difficult for me to get rid of since I've become quite accustomed to using it. For the time being, however, I'll switch back to using the quite capable gThumb. Also since F-Spot uses a weird format for storing data (meaningless directory structures etc), there will be some effort required in converting it to something that makes sense to use with gThumb.

Beagle has already been replaced by the much faster, leaner, and command line friendly Tracker. This was a switch that would have happened regardless of Novell's actions, so I've got no problems there. I'll not go into great detail about Tracker now since this would probably warrant its own post, but this is a project that I hope has a bright future.

Removing Mono and all (I think) related packages from your Ubuntu install is as easy as:

sudo aptitude remove libmono0

That will remove all kinds of stuff, including the ubuntu-desktop package. Read the list of packages before pressing Y so that you have no suprises. As of Edgy, Ubuntu ships with Mono since Tomboy and F-Spot are in the default desktop configuration. I am curious to see where Canonical takes this, if anywhere at all. It's probably about time I moved on anyways.

PS: To all of you who are pointing at me, laughing, and shrieking "I told you so!", yeah yeah I know... I guess I should have seen this coming.

Beep, SSH, and Perl 101

2006-11-15T19:06:00.001-05:00

I typically have my IRC client running on a remote machine in a screen session so that I can SSH from my laptop and attach to that session from anywhere. This is a great system, but the one thing it lacked was audible notification of highlighted messages. For the last few months I've used the hilightwin.pl script so that any conversation that contains keywords of my choice gets displayed in a little window at the top of my screen. The script is sufficiently small enough that even though I don't know Perl, I was able to modify it so that any special message shows up there. After being away from my keyboard it's nice to know I haven't missed anyone just by glancing at this little window.

The only thing that this system lacked was an audible beep to alert me when these messages arrive. Too often I'm just on another workspace when someone is trying to talk to me, and if I could hear the alert, I could chat back at them. Anyways, irssi does have beep functionality, but it doesn't seem to work very well through an ssh/screen session. Already long story short, inserting one line of Perl into the hilightwin script solved the problem in a rather hackish, but effective manner.

system("ssh hostname beep -f 100 -l 50 -r 2 &> /dev/null");

This command simply opens an ssh session with my laptop (exchange hostname with the actual hostname, of course), and runs the beep command producing two relatively low, short beeps. They are easily distinguishable from the normal system beep. If passwordless logins are enabled, then you're golden. Not many people talk to me so this really doesn't add much traffic to my network :)

Gmail and Top Posting

2006-11-12T16:59:00.001-05:00

I know many have bitched about this in the past, so I won't go off on a rant now. I am curious though if Google has addressed this anywhere that I haven't seen. As in, have they so much as acknowledged the complaints at all? Even if there were some FAQ entry somewhere that said something lame like "We at Google have decided that top posting is best practise and have no plans to support bottom posters." that would provide a feeling of closure. Instead, each time the New Features indicator appears I jump all over it hoping that today is the day. It never is.

Admittedly, I do feel like a bit of a knob even complaining or mentioning this at all. It's not that big of a deal to delete the space at the top, trim the replied text, and add my reply to the bottom. Also, I understand that Windows users are the majority and that Google probably doesn't wish to confuse them. But at least acknowledge good form and provide a non-default setting so that the geeks of the world who do give a shit feel loved too.

Am I alone here?

The GnuCash and Ledger Combo

2006-11-11T18:09:00.001-05:00

For the past month I've been using the excellent GnuCash 2.0 accounting package to keep track of our (my wife's and mine) finances. It's a quality accounting package with a quick double-entry accounting style, but I found it lacking a quick and flexible querying and reporting feature. Actually this is not true. I understand the built-in reporting features are quite extensible if you are familiar with Guile, and I mean, who isn't?

Anyways, just yesterday, an article at Linux.com pointed me to a package called Ledger. I'll not go into great detail about the package since the linked article does a pretty good job, but suffice it to say, that it is everything we've all grown to love in a powerful command line tool. It's very fast, and very powerful (with the use of regular expressions). Of course, it doesn't produce the prettiest of reports, but it does get the information you are looking for very quickly. It even has the option to output the matching entries to your query in XML format if you wish. I think I can see some Python report generating scripts in my future :).

As the article mentions, the package can read the data files that are produced by GnuCash. Instead of manually editing the Ledger data file as a method of entering transactions, I think I'll stick to using GnuCash as it has a very fast and efficient flow with autocompletions and all that goodness. The Ledger tool, however, is perfect for quick queries and reporting from one of my always open terminals. I think these tools will have a long and harmonious life on my desktop.

Disable Touchpad While Typing

2006-11-01T10:43:00.001-05:00

I ran across this blog entry while browsing around aimlessly yesterday that I think will play a large part in keeping my sanity. It drives me crazy when I accidentally touch the touchpad on my laptop while typing, and the cursor ends up being moved to some random spot on my desktop where my typing resumes.

I'm not sure why this little tip is not more widely known, but I think it should be. Especially since it's so easy to do. Ensure the line Option "SHMConfig" "on" appears in the appropriate Input Device section in your /etc/X11/xorg.conf. Then stick the command sysdaemon -t -d in your list of session startup commands. Here's the appropriate section of my xorg.conf file for reference:

Section "InputDevice"
        Identifier         "Synaptics Touchpad"
        Driver             "synaptics"
        Option             "SendCoreEvents"         "true"
        Option             "Device"                 "/dev/psaux"
        Option             "Protocol"               "auto-dev"
        Option             "HorizScrollDelta"       "0"
        Option             "SHMConfig"              "on"
EndSection

Done.

Retrieving Your BloggerBeta Blog ID

2006-10-30T10:59:00.001-05:00

Some people are wondering how to programatically get the blogID that the Google Data API page keeps referring to. I'm not sure if this is the best way or not, but I've had success using the following method in Python:

def getBlogID(uri):
    import httplib2, re
    con = httplib2.Http()
    response, content = con.request(uri, 'GET')
    match = re.search('blogID=(\d*)', content)
    if match:
        return match.group(1)
    else:
        print "BlogID retrieval failed."

It's quite simple actually, it takes your blog's URL as a parameter (as in http://whatever.blogspot.com), and sends an empty GET request to it. The response returned contains a string that matches the regular expression blogID=(\d*). That is, the string "blogID=" followed by a bunch of numbers. That bunch of numbers is the blogID. The function shown above extracts that number with a regular expression, and returns it.

GNOME-Terminal Vim with 256 Colors

2006-10-27T18:00:00.001-05:00

All this time I've been using Vim in 8 color mode assuming that my terminal (gnome-terminal) didn't support anything better. Well when using libvte version 0.13.0 or newer, it can support up to 256 colors! To pull this off in Vim is actually quite simple. You just need to tell Vim that your terminal can handle it, then use an appropriate colorscheme that takes advantage of the extra terminal colors. Telling Vim is as easy as set t_Co=256. After that download a colorscheme like desert256 to make it look all pretty-like.

There's a screenshot of my Vim, running in the terminal, using a modified version of desert256. The only modifications I made were to tone down the comments a bit (from cyan), and to alter the omni-completion menu from face-melting hot pink. If I didn't know better, I'd think that was GVim :)

Mastering the Vim Help System

2006-10-24T18:10:00.001-05:00

From hanging out in #vim on the Freenode IRC channel one thing I've noticed is that although the majority of people asking for support are more than willing to read the appropriate help topic, they are not familiar enough with the available tools to do so effectively. The Vim help system is surprisingly powerful, very well written, and very complete. This post is written to expose the Vim user to some of the less known tips about finding help within Vim.

The Basics

Given a command, or option, or any given topic that you'd like to find more information on, the best place to start looking for help is with the :help command. For example if you want to look up details on the expandtab option you would type :help expandtab to get to the appropriate section as shown below.

Navigation With Bookmarks

Throughout the help documentation, you will find many terms surrounded by | symbols like |these-ones|. These terms are references to bookmarks. If you put the cursor on one of these references and press <C-]>, you will jump to that reference's corresponding bookmark. Bookmarks in the documentation are surrounded by * characters like *these-ones*. You can jump from topic to topic as much as you like, and pressing <C-T> at any time will take you backwards one step.

In fact, you can try the <C-]> trick on any word in the help system to attempt a jump to a help section on that word. The explicit references are there to take you to a specific destination though.

Help Completion

Ensure that that wildmenu option is turned on (typing :set wildmenu will enable it) and you can have some nice help topic <Tab> completion. By typing :h (Note: :h is short for :help) followed by a partial word and a <Tab> you will be shown a list of help topics that begin with the given pattern. Pressing <Tab> repeatedly here will cycle through the option. Press <Enter> to select the topic you want. The following screenshot is the result of typing :h expa<Tab>.

Another useful tip when you only know a partial name is <C-D> (Ctrl-D) completion. By typing a partial name and pressing <C-D>, you will get a list of available topics containing that partial word. For example, the following picture is a result of typing :h cursor<C-D>.

Search Help Using Regular Expressions

For more complex searches, we can use the :helpgrep command. This command takes a regular expression as an argument and will return a list of all occurrences of a match found in the help documentation. For example, if you wanted to find all occurrences of the term double-click you would type :helpgrep double-click. The result of this command is shown below.

As you can see in the bottom of that screenshot, there were a total of 14 occurrences of this search term in the documentation. Each of these occurrences are displayed to you one at a time. To cycle to the next occurrence, use the :cn command. To cycle backwards, use the :cp command.

Keep Your Own Tips Section

This section doesn't cover more tools for searching the help documentation, but instead it suggests a way to take advantage of the help system itself to keep track of your own tips. This is a method I've been using for about a month now, and I've found it extremely helpful.

Start by creating a new text file in your ~/.vim/doc/ directory. Let's call it mytips.txt. Put the following line as the very first line of the new file.

*mytips.txt*  My own set of tips...

This is really the only line that matters as far as format goes. The rest of the file can be pretty much free form, but you will benefit by keeping it relatively organized. I keep mine divided up in sections, each section beginning with a bookmark like *mytips-movement*. With these bookmarks, I can jump to these sections immediately using the :h mytips-movement command just as I can jump anywhere else in the help system. In order to make your new file work as a help document, you need to run a command to generate a tags file for it like this: :helptags ~/.vim/d/oc

I have several autocommands in my ~/.vimrc to make this process a little more automated. If you'd like to use them, stick the following lines in your ~/.vimrc.

autocmd BufWrite mytips.txt             :helptags ~/.vim/doc/
autocmd BufRead  mytips.txt             set filetype=help
autocmd BufRead  mytips.txt             set noreadonly
autocmd BufRead  mytips.txt             set modifiable

nmap <leader>h :tabnew ~/.vim/doc/mytips.txt<CR>

The first one generates a new helptags file each time you write your tips file to disk. This keeps you from having to do it manually, and ensures your tips will always be current. The second sets the filetype to 'help' so that you get the appropriate syntax highlighting when you edit your file, and the following two undo a couple of unwanted options that setting the filetype enables automatically. Finally, <Leader>h is mapped to opening the new tips file in a new tab for editing (tabs are only in Vim7 or newer).

Now, when you discover a new tip, type <Leader>h (\h by default, see :he leader), add it to the file, and save it. Done!

Vim-Blogger Featuring Markdown

2006-10-22T18:15:00.001-05:00

Yes I'm still playing with this vim-blogger plugin. Now it has the ability to allow you to compose your post using John Gruber's Markdown syntax instead of plain ol' ugly html :). To accomplish this task, I am using a Python module for the conversion to HTML when posted.

Also cool is the fact that when a post is retrieved from your blog using this plugin, it is converted back to Markdown syntax using html2text. I think this is pretty cool. Here is a screenshot of me composing this post:

As you can see, I have a Vim syntax file for Markdown files too. I've modified it a bit to include vim-blogger specific things like the @@LABELS@@ line at the bottom etc. I do plan on making a release of this plugin at some point soon. It's too buggy just yet though. When I do, it will be composed of multiple files including the markdown and html2text Python modules, the syntax files, an ftplugin directory, and a regular (small) blogger.vim plugin file.

Using Markdown syntax has both advantages and disadvantages. The biggest advantage is the fact that it is easier to read and write when compared to HTML code. Also, it is rapidly becoming a popular method of writing structured text. A disadvantage is that the syntax still has some weaknesses. For example as of now there is no way to specify the size of an embedded image and there's no way to make it float right or left in your text. This can be done with embedded HTML, but then it would get messed up during the conversion back to Markdown in the context of this Vim plugin. For now though, it's fun to play with :).

Faster Buffer Switches in Vim

2006-10-21T12:56:00.001-05:00

I've tried several times in the past to use various buffer management plugins like the very popular minibufexplorer and bufexplorer only to find myself not using them or forgetting to use them after a few days. It seems that the normal "switch by name or number" method is faster and more convenient for me for some unknown reason. I can see how these plugins could be useful if your current number of open buffers gets huge, but until then I think they just take up valuable screen real estate (I'm pretty stingy about my screen space).

Buffers inherit their names from their file names. You can switch buffers by entering :b {name} or by :b {N} where {name} is either the full or partial buffer name that you desire (filename), and {N} is the buffer number. This by default has a number of issues.

Buffer numbers are difficult to remember unless you are a robot. Especially if the number of buffers is large.
If you have two buffers named file1 and file2 and you attempt to switch buffers with a command like :b file you will get an error message stating that there is more than one buffer matching that pattern.
If you have a buffer named Foo and you attempt to switch to it with a command like :b foo it will not work. Switching buffers by name is case sensitive.

In order to overcome these problems, I decided to modify this behaviour a bit to make my preferred method of buffer switching a little more user friendly. Of course before I began writing a function for it, I did a quick search through the tips at the Vim website and found this tip by Cory T. Echols. As suggested in a comment in this tip, this function prompts the user for a choice even if there is only one match to the given pattern. Also, it doesn't solve the case sensitivity problem mentioned above. I decided to work from this function and modify it to better suit my own tastes. First, instead of having a boolean switch for whether a pattern match was found or not, I used a List (Cory's function was written well before Lists were available in Vim. They are a Vim 7 feature.) and appended the number of matching buffers to this list. Once I've cycled through all of the listed buffers, if the length of this list is 1, I immediately make that buffer the active one. Only if there are more than one matching buffers do I prompt the user for a choice. I also chose to exclude unlisted buffers from my search. Unlisted buffers are ones that do not show up in the :ls list because they have been closed with the :bdelete command. I figure if I delete the buffer then I don't want to use it anymore. I only want to select a buffer from the listed ones.

Finally, I added a global variable called g:BufSel_Case_Sensitive that controls whether the match is case sensitive or not. It defaults to false, but can be changed anywhere (like your ~/.vimrc for example). This makes it much easier to swap if your edited file names contain a mix of upper and lower case characters.

The final product looks like this:

function! BufSel(pattern)
    let buflist = []
    let bufcount = bufnr("$")
    let currbufnr = 1

    while currbufnr <= bufcount
        if(buflisted(currbufnr))
            let currbufname = bufname(currbufnr)
            if (exists("g:BufSel_Case_Sensitive") == 0 || g:BufSel_Case_Sensitive == 0)
                let curmatch = tolower(currbufname)
                let patmatch = tolower(a:pattern)
            else
                let curmatch = currbufname
                let patmatch = a:pattern
            endif
            if(match(curmatch, patmatch) > -1)
                call add(buflist, currbufnr)
            endif
        endif
        let currbufnr = currbufnr + 1
    endwhile
    if(len(buflist) > 1)
        for bufnum in buflist
            echo bufnum . ":      ". bufname(bufnum)
        endfor
        let desiredbufnr = input("Enter buffer number: ")
        if(strlen(desiredbufnr) != 0)
            exe ":bu ". desiredbufnr
        endif
    elseif (len(buflist) == 1)
        exe ":bu " . get(buflist,0)
    else
        echo "No matching buffers"
    endif
endfunction
command! -nargs=1 -complete=buffer Bs :call BufSel("<args>")

It's not a real complicated function, but it does add a lot of flexibility when switching buffers via the command line. I added the following line in my ~/.vimrc to replace the already existing command when typed:

    cabbr b Bs

So now when I type :b (notice the space) it is replaced by :Bs automatically and the function is run instead of the built-in buffer command. This suggestion was also taken from the comments in the tip page above, and it works quite well.

Making ZZ Behave in Vim

2006-10-20T10:24:00.002-05:00

Update Apr 4, 2008: I was recently reminded of this post and thought I should mention that this particular solutions sucks. Although it won't break anything, it doesn't work well. Don't waste your time :) Cheers.

I've gotten quite used to the idea of hitting ZZ in Vim to kill the window I'm currently working in. The problem is that I'm so used to the idea, that I hit it almost automatically when I'm done with a particular buffer and there is only one window left. The result is that the Vim session is closed completely whether there is only one listed buffer or not.

My solution to this was not to find the probably existing command or setting built into Vim that corrects this problem, but rather to write a function that customizes the behavior of the ZZ command. This would be the first time I'd ever written a non-trivial function in pure Vim script, so I thought I'd give it a shot. The following function is the result. I've put lots of comments in there so that you can follow if you are new to Vim scripting like I am.

function! BehaveZZ()
    " Get the number of *listed* buffers.
    let highbuf = bufnr("$")
    let buflist = []
    let i = 1
    while (i <= highbuf)
        "Skip unlisted buffers.
        if (bufexists(i) != 0 && buflisted(i))
            call add(buflist, i)
        endif
        let i = i + 1
    endwhile
    let bufcount = len(buflist)
    if (bufcount == 1)
        if (bufname("%") == "")
            " This buffer is unnamed (has no associated file).
            if (&modified)
                " Give option to save modifications.
                let choice = input("Lose modifications? [Enter=yes]: ")
                if (choice == "")
                    set nomodified
                else
                    echo "ZZ action aborted..."
                    return
                endif
            else
                " The buffer has no modifications. Just do default ZZ.
                execute "x"
            endif
        else
            " There is only one listed buffer and it is named. In this case, 
            " the standard ZZ works just fine, so do that.
            execute "x"
        endif
    elseif (getbufvar(bufnr("%"), "&buftype") != "")
        " This buffer is a "special" buffer.
        execute "bdelete"
    elseif (bufname("%") == "")
        " This buffer is unnamed (has no associated file).
        if (&modified)
            " Give option to save modifications.
            let choice = input("Lose modifications? [Enter=yes]: ")
            if (choice == "")
                set nomodified
            else
                echo "ZZ action aborted..."
                return
            endif
        endif
        if (winnr("$") > 1)
            " There are multiple windows open. Just do a normal ZZ.
            execute "x"
        else
            execute "buffer! " . bufnr("#")
        endif
    else
        " This is a named buffer. 
        if (&modified)
            execute "write"
        endif
        if (winnr("$") > 1)
            " There are multiple windows. Just do normal ZZ.
            execute "x"
        else
            " There is only one window, but multiple listed buffers.
            let curbuf = bufnr("%")
            " If we have a 'last visited' buffer, go there. Else bnext.
            if (bufnr("#") != -1)
                execute "buffer! " . bufnr("#")
            else
                execute "bnext"
            endif
            execute "bdelete" . curbuf
        endif
    endif
endfunction
command! ZZ call BehaveZZ()

Now at the time of this writing, the above function has had very limited testing, so if you want to use it, beware. This is what the function does.

If there are multiple windows open, just close the current one. (Same as default ZZ)
If there is only one window open, but multiple buffers, delete the current buffer and switch to another one.
If there is only one window, and only one listed buffer, exit the session. (Same sd default ZZ)
If the current buffer is unnamed (ie. has no filename associated with it), confirm loss of modifications. If user presses just Enter, then discard modifications and delete the buffer. Else abort.

One behaviour of the default Vim that I found odd is a result of opening multiple files from the command line at once like vim file1 file2. When you do this, and try to close one you get a E173: 1 more file to edit message, and nothing happens at all. It however gives no such warnings if you open only one file, then open a second with the :e file2 command from inside the editor. This time it just closes the whole session if there is only one window open. In both of these cases, my function will close the currently active buffer and switch to one of the other buffers in the buffer list.

I think I've handled most special cases where a buffer is special like a help buffer, or a scratch buffer too. Initially I made it so that if the current buffer was unnamed and modified then the modifications would just be discarded, but that made me nervous so I added a one key confirmation just to be safe. The whole function turned out to be a lot more complex than I thought it would (not to mention longer). Things like special buffers gave me a lot of grief. Being new to this, the whole snippet probably ended up being more complicated than it needed to be. If you see any bugs or optimizations, I'd be interested in hearing about them. Leave a comment after this post.

To use this function, drop it into your ~/.vimrc and either :call it manually or map a key to it like

:map ZZ :call BehaveZZ()<CR>

. That's the mapping I use and it simply replaces ZZ's normal behavior with the new one.

See the Vim-BloggerBeta Plugin in Action

2006-10-14T13:23:00.001-05:00

I made a funky flash screencast of my vim-blogger plugin in action for all to see :). The screencast demonstrates saving a draft post, retrieving a list of all posts on the blog, editing a saved post, publishing a post, adding labels to a post, and finally deleting a post. The swf file ended up being quite large, but hopefully managable, and since Blogger doesn't allow hosting such files (yet?), I have to host it on my slow home server for now. Let me know if it is unbearably slow.

I do plan on releasing the plugin some day soon so all Vim/Blogger-beta users can make use of it, but first it needs some serious testing. The last thing I want to happen is for me to make it available too early, then have somebody pooch their data because of it. That and the thing is a bloody mess. I wrote it while discovering how to use the Blogger GData API, and the code shows it. Once it's in a safe state that I don't mind putting my name on, I'll make it public ;p.

Until then, enjoy the screencast, and leave comments or suggestions if you have any!

Success! Posting to Blogger-beta Using Vim

2006-10-13T15:37:00.001-05:00

If you see this, then I've finally (at least partially) figured out how to use the Blogger-beta GData API from Python. And to make posting a little bit quicker/easier for me, I've stuck that Python code into a Vim plugin.

To be honest, I'm not entirely sure what I was doing wrong in my previous attempts. I've changed several things, then changed some back. The resulting code really doesn't look much different to me than it did before, but there are a few very subtle changes. I suspect my ignorance when it comes to HTTP and XML protocols played a large part in my frustrations.

Anyways, here is a working version of the Python code that works for posting a blog entry. You will obviously need to fill in your BLOGID, GMAIL_ADDRESS, and GMAIL_PASSWORD appropriately for it to work for you:

#!/usr/bin/env python

import httplib2, re

account = "GMAIL_ADDRESS"
password = "GMAIL_PASSWORD"
blogid = "BLOGID"

def authenticate(h):
    auth_uri = 'https://www.google.com/accounts/ClientLogin'
    headers = {'Content-Type': 'application/x-www-form-urlencoded'}
    myrequest = "Email=%s&Passwd=%s&service=blogger&service=TestCompany-TestApp-0.0" % (account, password)
    response, content = h.request(auth_uri, 'POST', body=myrequest, headers=headers)
    if response['status'] == '200':
        return re.search('Auth=(\S*)', content).group(1)
    else:
        return None

entry = """<?xml version="1.0" ?>
    <entry xmlns='http://www.w3.org/2005/Atom'>
      <title type='text'>Test Post</title>
      <content type='xhtml'>
        <div xmlns="http://www.w3.org/1999/xhtml">
        If you are reading this, then it worked!
        </div>
      </content>
      <author>
        <name>TestUser</name>
      </author>
    </entry>
    """

h = httplib2.Http()
uri = 'http://www.blogger.com/feeds/%s/posts/full' % blogid

# Get the Auth token from ClientLogin
auth = authenticate(h)
if auth:
    headers = {'Content-Type': 'application/atom+xml', 'Authorization': 'GoogleLogin auth=%s' % auth.strip()}
    response, content = h.request(uri, 'POST', body=entry, headers=headers)

    # blindly follow redirects
    while response['status'] == '302':
        response, content = h.request(response['location'], 'POST', body=entry, headers=headers)

    if response['status'] == '201':
        print "Entry successfully posted."
    else:
        print "Post failed: %s" % response['status']
else:
    print "Authorization failed."

It's pretty rough, I realize, but I think it's good enough to get anyone started if you are interested. I hope someone will find this useful.

Now to see what other functionality I can perform :).

Oh, I almost forgot. If you want the Vim plugin I'm using you can get it here. To install it, drop it in ~/.vimrc/plugins/. To use it, open vim, type your post's subject on the first line, the post body below that, and type :BlogPost when you are done.

Blogger Template Customization

2006-10-11T16:34:00.000-05:00

Today I decided to customize my Blogger template a little bit to make it differ from the typical cookie cutter blogs on here. I'm not an expert on CSS and HTML by any means, but I think I'm pleased with the results so far. Aside from the shot of my ugly mug I stuck up there at the top of the page, I think it's fairly easy on the eyes. Of course, I've only viewed it with Firefox, so if you see any errors or problems with the page layout at all, please let me know.

By the looks of it, one pretty much has complete control over the look and feel of their Blogger-beta website. I could touch and edit pretty much every aspect of the page from what I could see. Like I said, however, I'm no expert so I didn't want to delve too deeply into things for fear of messing them up beyond repair.

A Step Closer to Google Authentication?

2006-10-11T11:00:00.000-05:00

Thanks to a comment left by Frank Mantek regarding the issue I was having with my Blogger-beta authentication, I've been able to get a step closer (I think?) to success. Frank was correct in his assumption that I was getting a 302 redirect response from the ClientLogin URL, and that my custom headers weren't being resent to the new URL. The response I got was a dictionary which contained of course the status code of 302, and also a location key with a value of http://beta.blogger.com/feeds/BLOGID/posts/full. Being quite new to all of this HTTP stuff, I can only assume that location is where the redirect was pointing to. I then implemented a test on the return status code, if it is 302, I manually resent the post and custom headers to the new location, and got a new error!

The new error is a 400 Bad Request error, and the content says GoogleLogin auth token is malformed. A search online for that error string revealed a guy with the same problem, but no responses. Since that thread was too old to reply to and revive, I had to start a new and similar thread. Hopefully it'll get some action.

I won't post all of the new code as most of it remains unchanged. I simply modified the getPost() function to take the URL to make the request to. The new stuff looks like this, with the test for redirect included:

h = httplib2.Http()
uri = 'http://www.blogger.com/feeds/BLOGID/posts/full'

cert = authenticate()
if cert:
    response, content = postEntry(cert, uri)
    while response['status'] == '302':
        cert = authenticate()
        response, content = postEntry(cert, response['location'])
    print response, content

Hopefully this is in fact a step closer. I'd love to get this working. Thanks for the comment and the help, Frank! :)

Send a Gmail Message from Vim

2006-10-10T05:42:00.000-05:00

Using Gmail on my laptop through the web interface can be quite time consuming. I use the Linux version of Firefox, and it's not exactly known around the world for its great speed. Anyways, sometimes I just want to shoot off a quick email, and it would take just as long to load the Gmail compose form as it would to type the email content. For these times I wrote a little vim-python script as follows:

" Make sure the Vim was compiled with +python before loading the script...
if !has("python")
        finish
endif

:command! -nargs=? GMSend :call GMailSend("<args>")

function! GMailSend(args)
python << EOF
import vim
to = vim.eval('a:args')
GSend(to)
EOF
endfunction

python << EOF
########### BEGIN USER CONFIG ##########
account = 'MY_GMAIL_ACCOUNT'
password = 'MY_GMAIL_PASSWORD'
########### END USER CONFIG ###########


def GSend(to):
    """
    Send the current buffer as a Gmail message to a given user.
    """
    import libgmail

    subject = vim.current.buffer[0]
    body = '\n'.join(vim.current.buffer[2:])

    ga = libgmail.GmailAccount(account, password)
    try:
        ga.login()
    except libgmail.GmailLoginFailure:
        print "Login failed. (Wrong username/password?)"

    gmsg = libgmail.GmailComposedMessage(to, subject, body)

    if ga.sendMessage(gmsg):
        print "Message sent `%s` successfully." % subject
    else:
        print "Could not send message."

EOF

It's a really simple script, and it uses Python so it will only work if your Vim was compiled with the +python option. Of course, you'll also need to edit the script to put in your own Gmail user name and password (lines 18 and 19).

Installation

Drop the above script (or download it from here) into your ~/.vim/plugin/ directory. Reload Vim or source the file with :so ~/.vim/gmail.vim.

Usage

It's even easier to use. The first line in the buffer is the email's subject, and the rest is the body. Once the email is composed in this fashion, type :GMSend <dest> where <dest> is the email address that you want to send this message to. If all is well, you'll see a message at the bottom of your Vim window indicating that all is well, and that the message was sent successfully.

Hopefully somebody out there will find this useful. The version I am actually using is a little more complex. I've extended the script to download messages by folder or label and stick the id, subject, and author in an active buffer. From there I can select one of the shown messages and the script will display the body in the same buffer. I've kept the rest to myself as I'm not real thrilled with the UI part, and I'm not sure it will work as expected for everyone. If you are interested, leave a comment. I'm pretty confident that the script posted above (the one that just sends mail) will work as expected. Enjoy!

Using the Google GData API with Python

2006-10-08T15:41:00.000-05:00

I did a very quick search online for examples that I could use to see how to interact with Google's GData API for creating and posting Blogger-beta blog entries. The best I could find was this post to Jon Udell's Infoworld weblog which illustrates making an entry to Google Calendar. Now even though it is a different web application, most of this example code is still relevent as apparently they use the same API.

From this, I tried the following code:

#!/usr/bin/env python

import httplib2

h = httplib2.Http()
h.add_credentials('MY_GMAIL_ACCOUNT', 'MY_GMAIL_PASSWORD')
h.follow_all_redirects = True
uri = 'http://www.blogger.com/feeds/BLOGID/posts/full'

post_xml = """
<?xml version="1.0" ?>
<entry xmlns='http://www.w3.org/2005/Atom'>
  <title type='text'>Test Post from Python</title>
  <content type='xhtml'>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p>If you can see this, then it worked!</p>
    </div>
  </content>
  <author>
    <name>Dennis</name>
  </author>
</entry>
"""

headers = {'Content-Type': 'application/atom+xml'}
response, content = h.request(uri, 'POST', body=post_xml, headers=headers)
print response, content

With this code, the last print line revealed a Error 401 of Missing auth parameter in GoogleLogin. I assumed that there was a problem with the method of authentication in the httplib2 library. Possibly it was out of date as apparently this API is a bit of a moving target still these days. As a result, I had a look at the Google Account Authentication docs to see if I would have better luck doing the authentication manually. After a bit of fiddling, I ended up with this:

#!/usr/bin/env python

import httplib2
import re

def postEntry(auth):

    entry = """
    <?xml version="1.0" ?>
    <entry xmlns='http://www.w3.org/2005/Atom'>
      <title type='text'>Test Post from Python</title>
      <content type='xhtml'>
        <div xmlns="http://www.w3.org/1999/xhtml">
          <p>If you can see this, then it worked!</p>
        </div>
      </content>
      <author>
        <name>Dennis</name>
      </author>
    </entry>
    """

    headers = {'Content-Type': 'application/atom+xml', 'Authorization': 'GoogleLogin Auth=%s' % auth.strip()}
    response, content = h.request(uri, 'POST', body=entry, headers=headers)
    print response, content

def authenticate():
    auth_uri = 'https://www.google.com/accounts/ClientLogin'
    headers = {'Content-Type': 'application/x-www-form-urlencoded'}
    myrequest = "Email=MY_GMAIL_ACCOUNT&Passwd=MY_GMAIL_PASSWORD&service=blogger&service=Dcraven-TestApp-0.0"
    response, content = h.request(auth_uri, 'POST', body=myrequest, headers=headers)
    if response['status'] == '200':
        return re.search('Auth=(\S*)', content).group(1)
    else:
        return None

h = httplib2.Http()
h.follow_all_redirects = True
uri = 'http://www.blogger.com/feeds/BLOGID/posts/full'

cert = authenticate()
if cert:
    postEntry(cert)

The result of this was exactly the same thing, although the actual authenticate() function worked fine, so the problem doesn't lie there. The response from the POST call in this method was in fact 200, and I did get an Auth code from the server. Even after manually packing this code into the header as specified by the Google documentation, I still got an Error 401: Missing auth parameter in GoogleLogin returned by the postEntry() function.

I think this code should work, but alas, it does not. If anyone has any ideas why, or can spot an error in the code I'd really appreciate you pointing it out in a comment below. In the meantime I think I'll make posts the old fashioned way until I get the ambition to try again.

NOTE: I suppose I should note that in the above code, the words BLOGID, MY_GMAIL_PASSWORD, and MY_GMAIL_ACCOUNT actually contained the appropriate values when I tried to run the program :)

UPDATE: I just wanted to post this update for anyone landing here from a Google search or something. I ended up having success with this as posted here.

VimPastebin - Post to Pastebin from within Vim

2006-10-08T05:47:00.000-05:00

The VimPastebin script is a Vim plugin script that posts selected text to the Pastebin of your choice and optionally sends the URL to your pasted text as Gajim message to someone in your roster. The syntax is chosen from the current filetype in the Vim editor. For example, if you are editing a Python file, the text sent to Pastebin will automatically be highlighted with Python syntax.

Requirements

This script is mostly written in Python, so it will only work if your Vim was compiled with the --enable-pythoninterp=yes configure option. To see if your installed Vim is compiled with this option, simply type the :version command inside Vim and look for +python. If you see -python in the list, this script will not work, otherwise you're golden!

Installation

Drop this script into your ~/.vim/plugin directory or somewhere else in your $VIMRUNTIME path. It will be sourced automatically next time you start Vim. You can source it manually by typing :source /path/to/script if you like.

There are a couple of configuration options in the script that should be modified for your particular settings. You can set your preferred Pastebin on line 38, and your preferred username on line 40. By default, the script included on this wiki page will post to http://pastebin.com as the user "vimuser".

Usage

To use the script is very simple. Just visually block (Shift-v) the lines of code you want to send to the Pastebin and enter the command :PasteCode. The blocked text will be sent to the Pastebin and the new URL will be shown on the Vim statusline. Optionally, you could enter the command :PasteGajim somename@somejid.org to send the new URL to the JID somename@somejid.org providing that JID appears in your roster. To make it even easier, you can send it to someone in your roster by only specifying their name, like :PasteGajim dcraven will send it to user name dcraven. This is handy if you cannot remember the person's full JID.

That's It!

That's pretty much all there is to it. If you missed the link to the actual script above, you can download it here. Enjoy!

Here's the code if you just want to have a quick look:

" Make sure the Vim was compiled with +python before loading the script...
if !has("python")
        finish
endif

" Map a keystroke for Visual Mode only (default:F2)
:vmap <f2> :PasteCode<cr>

" Define two commands.. One for just pastebinning alone, and another for
" Gajiming the results
:command -range -nargs=* PasteCode :call PasteMe(<line1>,<line2>,"None")
:command -range -nargs=* PasteGajim :call PasteMe(<line1>,<line2>,"<args>")

function! PasteMe(line1,line2,args)
python << EOF
import vim

line1 = vim.eval('a:line1')
line2 = vim.eval('a:line2')
jid = vim.eval('a:args')
format = vim.eval('&ft')

url = PBSend(line1, line2, format)
if not jid == "None":
    gajim_send_url(jid, url)
print "Pasted at %s" % url
EOF
endfunction

python << EOF
import vim
from urllib2 import urlopen
from re import compile

def PBSend(line1, line2, format='text'):
################### BEGIN USER CONFIG ###################
    # Set this to your preferred pastebin
    pastebin = 'http://pastebin.com'
    # Set this to your preferred username
    user = 'vimuser'
#################### END USER CONFIG ####################

    supported_formats = {
        'text' : 'text', 'bash' : 'bash', 'python' : 'python', 'c' : 'c',
        'cpp' : 'cpp', 'html' : 'html4strict', 'java' : 'java',
        'javascript' : 'javascript', 'perl' : 'perl', 'php' : 'php',
        'sql' : 'sql', 'ada' : 'ada', 'apache' : 'apache', 'asm' : 'asm',
        'aspvbs' : 'asp', 'dcl' : 'caddcl', 'lisp' : 'lisp', 'cs' : 'csharp',
        'css' : 'css', 'lua' : 'lua', 'masm' : 'mpasm', 'nsis' : 'nsis',
        'objc' : 'objc', 'ora' : 'oracle8', 'pascal' : 'pascal',
        'basic' : 'qbasic', 'smarty' : 'smarty', 'vb' : 'vb', 'xml' : 'xml'
    }

    if not (pastebin[:7] == 'http://'):
        pastebin = 'http://' + pastebin

    code = '\n'.join(vim.current.buffer[int(line1)-1:int(line2)])
    if format in supported_formats.keys():
        data = "format=%s&paste=Submit&code2=%s&poster=%s" % \
                (supported_formats[format], urlencode(code),
                urlencode(user))
    else:
        data = "format=text&paste=Submit&code2=%s&poster=%s" % \
                (urlencode(code), urlencode(user))

    u = urlopen(pastebin, data)
    f = "".join(u.readlines())
    rx = compile("<a.*?/(\d+)\">")
    ar = rx.findall(f)
    if len(ar) > 0:
        url = pastebin + '/' + ar[0]
        return url
    else:
        print 'An error occured.'

def gajim_send_url(jid, url):
    try:
        import dbus
        sbus = dbus.SessionBus()
        obj = sbus.get_object('org.gajim.dbus', '/org/gajim/dbus/RemoteObject')
        interface = dbus.Interface(obj, 'org.gajim.dbus.RemoteInterface')

        # Try to get the actual JID from your contact list
        list = interface.__getattr__('list_contacts')
        roster = list()
        for contact in roster:
            if jid.lower() == contact['name'].lower():
                jid = contact['jid']

        send = interface.__getattr__('send_message')
        if not send(jid, url):
            print "%s not found in Gajim roster." % jid
    except:
        print "Error sending message to %s." % jid

def urlencode(data):
    out = ""
    for char in data:
        if char.isalnum() or char in ['-','_']:
            out += char
        else:
            char = hex(ord(char))[2:]
            if len(char) == 1:
                char = "0" + char
            out += "%" + char
    return out
EOF

Screw it... Let someone else host my crud :)

2006-10-07T16:53:00.000-05:00

I've decided to migrate my own blog from my home server to here to see how it works out. I hardly ever make posts, and my hardware is unreliable. If I put it here, then maybe I can forget about it altogether. The hard/painful part is migrating all (3?) of my posts from my old home to here. heh