Tuesday, October 12, 2010

Colorizing and autopaging svn diffs and other commands

I can't remember the last time I jacked off to black and white pornography.

Can you?

OF COURSE YOU CANT! Color is fucking awesome! No one yanks their crank to black and white shit anymore.

Once you've tasted color, you can never go back.

This brings us to the subject of version control. Over the last few years I've been spoiled by git, but have recently switched jobs and been using svn again. Using git has taught me to actually care what I'm committing — as opposed to just creating one giant commit at the end of the day — which has meant I've been looking at lots of diffs.

Git gives you lovely colorized, paged diffs that frequently stiffen the schlong. While svn, on the other hand, still gives you the same uncolored, unpaged horse shit as it did several years ago! I can't fucking believe the meat puppets at svn haven't gotten their asses into gear and stolen some basic UI ideas from the competition. WTF guys?!

Here's how you enable color for everything in git:

git config --global color.ui always

There are more granular options if you want them, but fuck that, color is awesome!

Svn has no such option. So I, like many others, have been forced to hack the mainframe to get color. Check my hacks:


This script defines a function called "svn" that hijacks calls to the svn program and essentially rewrites some of the commands. For example, this command:

svn diff -r1:7 foo

would get rewritten to:

svn diff -r1:7 foo | colordiff | sed -e 's/\r//g' | less -RF

Another example:

svn log foo

would get rewritten to:

svn log foo | less -F

Notice that I'm still interacting with svn via the same command set, and am not training myself away from the existing commands. Hopefully this will prevent me from losing the plot and ripping off cocks when forced to use svn on a machine that doesn't have my hacks.

Tuesday, July 13, 2010

Vim pr0n: Sample NERD tree plugins

I'm a lazy wank, and additionally: a bastard.

Which brings us nicely to our next point: The NERD tree API. In version 4.0 I added an API to allow people to add functionality to the NERD tree in the form of plugins.

I did this because I was getting tired of politely telling people where to ram requests for features that I either A. Would never personally use and therefore would probably do a poor job of maintaining, or B. Thought were good ideas, but was not interested in taking the plugin in that direction.

As a result, I've ended up writing a lot of small NERD tree plugins for people who have requested such features. In this raving I'll post and explain a couple of the simpler examples.

API Technical Details

You can get technical information about the API from :help NERDTreeAPI. Here you will find the documentation on the interface functions and some short usage examples. I spent ages writing that shit, so go check it out!


I see you've ignored my advice. You suck! However, in a rare show of generosity, I'll summarize it for you.

At the time of this writing the following public functions are defined in the NERD tree core:

NERDTreeAddKeyMap({options})
NERDTreeAddMenuItem({options})
NERDTreeAddSubmenu({options})
NERDTreeAddMenuSeparator([{options}])
NERDTreeRender()

The first 4 deal with extending the NERD tree key set and menu system, while the last redraws the tree buffer (useful if you have changed the tree somehow and want to reflect that in the UI).

Additionally, the following public classes are available:

NERDTreePath
NERDTreeDirNode
NERDTreeFileNode
NERDTreeBookmark

These are what the NERD tree core uses to get most of its biznass done. I wont say any more about them other than check out the source code, and check out this blog post to see the coding conventions used and for a rundown of prototype OO in Vim.

Example 1: A key mapping to open a :shell

In this example we add a key mapping on 'S' to the NERD tree that launches the :shell command in the directory of the currently selected node.


Even though I commented the living shit out of the code, it's probably worth mentioning the three points in this code where we call the NERD tree API:
  • Lines 8–11. Here we set up the NERD tree key binding so that when the user hits 'S', the NERDTreeStartShell() function is invoked. The quickhelptext value is what appears in the quick help (i.e. when you hit '?') under the "Custom mappings" section.
  • Line 18. Here we call GetSelected() (a class method of NERDTreeDirNode). This gives us a NERDTreeDirNode instance representing the directory node the cursor is sitting on.
  • Line 26. Here we call n.path.str(...) which gives us a string representation of the NERDTreePath object for the node in question, suitable for use with a :cd command. There are a number of formats and options the str() method can take. Check out the method comments in NERD_tree.vim for details.

Example 2: A menu item to open images

In this example we add a menu item to view images with eog. We could easily extend this to support some default image viewers for MF Windows™ and Mac OSX, but for simplicity, that has been left out.



Here is an image of the above code in action (after hitting 'm' on an image node):

The code is responsible for the last 2 lines of the menu. Some highlights:
  • Lines 13 and 14 add the menu separator (the line of dashes).
  • Lines 17–21 add the (v)iew image menu item.
  • Lines 14 and 20 ensure that the menu items only appear when the cursor is over an image node.
  • Line 21 connects the menu item to the NERDTreeViewImageMenuItem() function which shells out to eog to open the image.

Final ravings

We've seen a couple of basic examples of NERD tree plugins that show how to add additional key mappings and menu items. I've written many more such plugins, which have mostly been for the purposes of integrating the tree with external programs (e.g. git and grep), or with other vim plugins (eg UTL). I've also written plugins that add slightly modified versions of existing key mappings, or even override the existing mappings.

One day I may stop watching pr0n long enough to clean up and post some more complex examples. Until then, try to behave yourselves, and flick me an email if you write any dynamite NERD tree plugins!

Monday, June 28, 2010

Hacking line numbers into embedded gists

Github has the only corporate mascot in existence that I fantasize about touching inappropriately.




When github unveiled their gist service in 2008, I went into my room, jumped up on my bed, ripped all the playboy posters off the ceiling and taped up a giant portrait of the octocat.

But HOT DAYYUMN is github's lack of line numbers on their embedded gists pissing me off! I've been trying to write another raving containing a reasonable amount of code that is explained over the course of the post — pretty fucking hard without line numbers!

So I went and wrote some javascript hacks to add line numbers in for me.

The hacks

I originally tried to do it with prototype, but was having so much trouble getting it to work on IE6 that I decided to try out jquery instead. Cunting fuck I hate fucking Internet Explorer 6! Ive lost count of the number of rape fantasies I've had about Bill Gates! Anyway, check out these hacks below — maximum credit goes to gaving for refactoring them into not sucking.



Notice those line numbers? ZOMG!


How to use said hacks

Its easy, check out this example:

Its worth noting that the url for the "line number hackz0r script" is from the "view raw" link of the previous gist. If you remove the SHA1 from the url, it seems it always grabs the latest revision of the gist.

Saturday, May 8, 2010

How csplit turned my software into hardware

I'm typing this text with my penis.

This is made possible largely due to the erection inducing side-effects of csplit — a program I'd never used until today.

Story time!

Once upon a time in a far distant land, there was a handsome, charming, young prince who had never known true love... Meanwhile, somewhere else, I was sitting at my desk, scratching my head, wondering how the cunting fuck I was going to extract the tiny part of this 1.8GB database dump that I needed. The dump was generated with something like
mysqldump --all-databases > all_databases.sql
giving me a file with a metric fuck-load of sql to create databases, and insert data into them — from which I needed one particular database.

Of course I tried to edit it with Vim first (before realizing how large it was) and had to kill it before it started eating into my swap. Gedit gave me similar results, and Emacs just told me to fuck off. However, a quick trip to google gave me the answer: csplit! Following which my four foot blackzilla punched a hole through the front of my jeans and stabbed me in the eye.

Anyway, I went over to my dump file and grepped the bastard to find out the order that the "CREATE DATABASE" statements appeared in and then snipped out the one I wanted with these hacks (where foo_database is the database I wanted to extract, and bar_database is the next one in the file):
csplit all_databases.sql '/CREATE DATABASE.*foo_database/' '/CREATE DATABASE.*bar_database/'
This outputted three files (xx00, xx01, xx02):
  • xx00 containing everything up to the first match of /CREATE DATABASE.*foo_database/ (a regex)
  • xx01 containing everything between the two regexes (including the line matching the first regex)
  • xx02 containing everything after the second regex (/CREATE DATABASE.*bar_database/)
This put the code that I wanted into xx01. Very handy!

A related tool that could also have been useful is plain split. For example

split --bytes=10000000 a_large_file
would split a file up into 10MB chunks.