FrogBlog

For a long time I had problems finding a way to organize arbitrary snippets of information on my computer. I tried several things from simply storing arbitrary text files in the normal directory structure to trying out various note-kepping programs. I even considered writing one of my own.

Several weeks ago I finally found the ideal solution for me — at least from my current experience it seems to be the ideal solution: Viki. This is a vim script that adds wiki functionality to vim.

Now I can keep my notes semi-structured (i.e. cross-referenced) — and my todo list. I even started organizing my web browser bookmarks with Viki (you can invoke an external link in your web browser from within vim with the Viki scripts).

I also use Mercurial to put my notes in a revision control system. This allows me to easily distribute my notes across different computers and keeping them in sync (with the side-effect to get light-weight backups).

I am long-time vim user. For some years I also use a Mac. Last year I discovered the MacVim project. This is a Cocoa based GUI to vim (so far there was only gvim on the Mac, a Carbon based GUI).

The Carbon gvim is not that great so I sticked to the console vim version. But with the new MacVim, I now have a GUI vim that not only looks much better but also has additional features:

• It has a fullscreen mode.
• Vim’s tab feature uses real tabs instead of ASCII-art tabs.
• There is an ODB input manager that adds an “Edit in MacVim” menu entry to all applications (see Edit in SubEthaEdit for the principle).

There are probably other things, but those are the three I really like. With the “Edit in MacVim” feature, I can now easily write my mails from Apple Mail in vim. Unfortunately, the feature does not work for me in Camino.

When I commute to work I typically listen to podcasts. My favorite podcast is Chaosradio Express, a podcast in German about technology (often with social aspects on it as well). In its latest episode Moderne Webentwicklung Tim Pritlove (the host of the podcast) talks with the two developers of Soup.

Soup is a Tumblelog and they explain in the beginning that the concept of a tumblelog is to propagate really short blogs. To cut a story short: the problem I have with writing blogs is that i don’t feel like writing full-fledged articles all the time (I am a somewhat lazy person). But now I realize that it is not needed at all and I plan to write more often blog entries with some short info or tips (they won’t be as short as tumblelogs, though).

So stay tuned. This blog is not dead (although it almost looks like it is from the frequency of articles lately).

A while ago, KDE branched the 4.0.x releases into their own subversion branch directory. This reminded me that I’ve been using a little script for a while which comes in quite handy when you want to commit a patch to multiple branches.

The script is called ‘ilc’ (which originally stood for ‘integrate last change’ but it actually integrates any revision you specify) and can be found at http://ktown.kde.org/~frerich/ilc. It’s a little Bash script which expects you to have separate checkouts for the different branches (so it doesn’t integrate the change “in place”).

For instance, in my directory layout, there’s the KDE trunk checkout in ~/src/kde/trunk and the KDE 4.0.x branch checkout in ~/src/kde/40. I usually work in the trunk branch, but every now and then I want to backport something (usually a bugfix) to the 4.0.x branch. So after hacking away, I eventually do this:


frerich@helios:~/src/kde/trunk/kdenetwork/knewsticker$ svn ci
Sending settingsdialog.cpp
Transmitting file data .
Committed revision 765024.
frerich@helios:~/src/kde/trunk/kdenetwork/knewsticker$


So SVN gave me the number of the revision I just committed. Using the ilc script, all I need to do to integrate this change into the 4.0.x branch is


frerich@helios:~/src/kde/trunk/kdenetwork/knewsticker$ ilc 765024 ~/src/kde/40


The script will make sure that the affected files in the 4.0.x checkout are up to date, then apply the patch, and finally it’ll let me inspect the patch it did, abort the merge, or commit. When committing, it’ll use the original log message plus a prefix like “automatically merged revision 765024:” so that I can lateron still see that this commit was actually a backport of something else.