# HG changeset patch
# User Steve Losh <steve@stevelosh.com>
# Date 1263604483 18000
# Node ID a6628e0d5710eb6b3ad9a33dd4d8a7b07564cbdd
# Parent  ce99be93f9c9937e7349f5dc7c75fd24f9133590
Properly codehilite the blog entries.

diff -r ce99be93f9c9 -r a6628e0d5710 content/blog/2008/08/beauty-in-computer-science-recursion.html
--- a/content/blog/2008/08/beauty-in-computer-science-recursion.html	Fri Jan 15 20:04:42 2010 -0500
+++ b/content/blog/2008/08/beauty-in-computer-science-recursion.html	Fri Jan 15 20:14:43 2010 -0500
@@ -114,6 +114,7 @@
 able to add any two (positive) numbers (integers) together. How could you do
 this? Here's a function:
 
+    :::text
     function add(x, y):
         if y = 0:
             return x
diff -r ce99be93f9c9 -r a6628e0d5710 content/blog/2009/01/deploying-site-fabric-and-mercurial.html
--- a/content/blog/2009/01/deploying-site-fabric-and-mercurial.html	Fri Jan 15 20:04:42 2010 -0500
+++ b/content/blog/2009/01/deploying-site-fabric-and-mercurial.html	Fri Jan 15 20:14:43 2010 -0500
@@ -69,7 +69,8 @@
 On your local machine, edit the `.hg/hgrc` file in the repository and change
 the default path to:
 
-	default = ssh://hg@bitbucket.org/username/repositoryname/
+    :::ini
+    default = ssh://hg@bitbucket.org/username/repositoryname/
 
 That will let you push/pull to and from BitBucket over SSH. Doing it that way
 means you can use public/private key authentication and avoid typing your
@@ -90,7 +91,8 @@
 you want to serve it from. Edit the `.hg/hgrc` file in that one and change the
 default path to the same value as before:
 
-	default = ssh://hg@bitbucket.org/username/repositoryname/
+    :::ini
+    default = ssh://hg@bitbucket.org/username/repositoryname/
 
 Once again, set up public/private key authentication; this time between the
 server and BitBucket. You can either copy your public and private keys from
@@ -133,35 +135,35 @@
 where to start.
 
 [Fabric]: {{links.fabric}}
-[WebFaction]: http://www.webfaction.com?affiliate=sjl
+[WebFaction]: {{links.webfaction}}
 
-	#!python
-	def prod():
-	    """Set the target to production."""
-	    set(fab_hosts=['sjl.webfactional.com'])
-	    set(fab_key_filename='/Users/sjl/.ssh/stevelosh')
-	    set(remote_app_dir='~/webapps/stevelosh/stevelosh')
-	    set(remote_apache_dir='~/webapps/stevelosh/apache2')
+    :::python
+    def prod():
+        """Set the target to production."""
+        set(fab_hosts=['sjl.webfactional.com'])
+        set(fab_key_filename='/Users/sjl/.ssh/stevelosh')
+        set(remote_app_dir='~/webapps/stevelosh/stevelosh')
+        set(remote_apache_dir='~/webapps/stevelosh/apache2')
 
-	def deploy():
-	    """Deploy the site."""
-	    require('fab_hosts', provided_by = [prod,])
-	    local("hg push")
-	    run("cd $(remote_app_dir); hg pull; hg update")
-	    run("cd $(remote_app_dir); python2.5 manage.py syncdb")
-	    run("$(remote_apache_dir)/bin/stop; sleep 1; $(remote_apache_dir)/bin/start")
+    def deploy():
+        """Deploy the site."""
+        require('fab_hosts', provided_by = [prod,])
+        local("hg push")
+        run("cd $(remote_app_dir); hg pull; hg update")
+        run("cd $(remote_app_dir); python2.5 manage.py syncdb")
+        run("$(remote_apache_dir)/bin/stop; sleep 1; $(remote_apache_dir)/bin/start")
 
-	def debugon():
-	    """Turn debug mode on for the production server."""
-	    require('fab_hosts', provided_by = [prod,])
-	    run("cd $(remote_app_dir); sed -i -e 's/DEBUG = .*/DEBUG = True/' deploy.py")
-	    run("$(remote_apache_dir)/bin/stop; sleep 1; $(remote_apache_dir)/bin/start")
+    def debugon():
+        """Turn debug mode on for the production server."""
+        require('fab_hosts', provided_by = [prod,])
+        run("cd $(remote_app_dir); sed -i -e 's/DEBUG = .*/DEBUG = True/' deploy.py")
+        run("$(remote_apache_dir)/bin/stop; sleep 1; $(remote_apache_dir)/bin/start")
 
-	def debugoff():
-	    """Turn debug mode off for the production server."""
-	    require('fab_hosts', provided_by = [prod,])
-	    run("cd $(remote_app_dir); sed -i -e 's/DEBUG = .*/DEBUG = False/' deploy.py")
-	    run("$(remote_apache_dir)/bin/stop; sleep 1; $(remote_apache_dir)/bin/start")
+    def debugoff():
+        """Turn debug mode off for the production server."""
+        require('fab_hosts', provided_by = [prod,])
+        run("cd $(remote_app_dir); sed -i -e 's/DEBUG = .*/DEBUG = False/' deploy.py")
+        run("$(remote_apache_dir)/bin/stop; sleep 1; $(remote_apache_dir)/bin/start")
 
 When I'm finished committing to my local repository and I want to deploy the
 site, I just use the command `fab prod deploy` on my local machine. Fabric
@@ -181,13 +183,13 @@
 All I'd need to do is add a `test` command, which might look something like
 this:
 
-	#!python
-	def test():
-	    """Set the target to test."""
-	    set(fab_hosts=['sjl.webfactional.com'])
-	    set(fab_key_filename='/Users/sjl/.ssh/stevelosh')
-	    set(remote_app_dir = '~/webapps/stevelosh-test/stevelosh')
-	    set(remote_apache_dir = '~/webapps/stevelosh-test/apache2')
+    :::python
+    def test():
+        """Set the target to test."""
+        set(fab_hosts=['sjl.webfactional.com'])
+        set(fab_key_filename='/Users/sjl/.ssh/stevelosh')
+        set(remote_app_dir = '~/webapps/stevelosh-test/stevelosh')
+        set(remote_apache_dir = '~/webapps/stevelosh-test/apache2')
 
 Deploying the test site would then be a simple `fab test deploy` command.
 
diff -r ce99be93f9c9 -r a6628e0d5710 content/blog/2009/03/candy-colored-terminal.html
--- a/content/blog/2009/03/candy-colored-terminal.html	Fri Jan 15 20:04:42 2010 -0500
+++ b/content/blog/2009/03/candy-colored-terminal.html	Fri Jan 15 20:14:43 2010 -0500
@@ -76,7 +76,7 @@
 
 [this guide]: http://www.ibm.com/developerworks/linux/library/l-tip-prompt/
 
-    #!bash
+    :::bash
     D=$'\e[37;40m'
     PINK=$'\e[35;40m'
     GREEN=$'\e[32;40m'
diff -r ce99be93f9c9 -r a6628e0d5710 content/blog/2009/03/mercurial-bash-prompts.html
--- a/content/blog/2009/03/mercurial-bash-prompts.html	Fri Jan 15 20:04:42 2010 -0500
+++ b/content/blog/2009/03/mercurial-bash-prompts.html	Fri Jan 15 20:14:43 2010 -0500
@@ -39,7 +39,7 @@
 Here's the code in my `.bashrc` file to create it. I've stripped out the color
 information to save space.
 
-    #!bash
+    :::bash
     export PS1='\n\u at \h in \w\n$ '
 
 I use the same prompt on every computer I work with, so with this prompt I can
@@ -67,7 +67,7 @@
 
 And here's the code in my `.bashrc` that does it:
 
-    #!bash
+    :::bash
     hg_in_repo() {
         hg branch 2> /dev/null | awk '{print "on "}'
     }
@@ -100,7 +100,7 @@
 
 And the code in `.bashrc`:
 
-    #!bash
+    :::bash
     hg_dirty() {
         hg status --no-color 2> /dev/null \
         | awk '$1 == "?" { print "?" } $1 != "?" { print "!" }' \
@@ -127,7 +127,7 @@
 to add colors directly in the functions, so here's the (much nicer) updated
 code all at once:
 
-    #!bash
+    :::bash
     DEFAULT="[37;40m"
     PINK="[35;40m"
     GREEN="[32;40m"
diff -r ce99be93f9c9 -r a6628e0d5710 content/blog/2009/05/what-i-hate-about-mercurial.html
--- a/content/blog/2009/05/what-i-hate-about-mercurial.html	Fri Jan 15 20:04:42 2010 -0500
+++ b/content/blog/2009/05/what-i-hate-about-mercurial.html	Fri Jan 15 20:14:43 2010 -0500
@@ -60,6 +60,7 @@
 I had to look up the syntax every single time I wanted to use this command,
 until I added this alias to my `~/.hgrc`:
 
+    :::ini
     [alias]
     untrack = rm -Af
 
@@ -73,6 +74,7 @@
 Here's what happens when you move a file and then use `hg addremove` normally
 to have Mercurial track the changes.
 
+    :::console
     sjl at ecgtheow in ~/Desktop/test on default 
     $ ls
     total 16
@@ -111,6 +113,7 @@
 Now watch what happens when we tell Mercurial to detect renames when using `hg
 addremove`:
 
+    :::console
     sjl at ecgtheow in ~/Desktop/test on default 
     $ ls
     total 16
@@ -162,6 +165,7 @@
 Assuming they're recorded, I wish `hg status` would show that a file has been
 renamed. Here's what we get instead:
 
+    :::console
     sjl at ecgtheow in ~/Desktop/test on default 
     $ hg rename b c
     
diff -r ce99be93f9c9 -r a6628e0d5710 content/blog/2009/06/how-to-contribute-to-mercurial.html
--- a/content/blog/2009/06/how-to-contribute-to-mercurial.html	Fri Jan 15 20:04:42 2010 -0500
+++ b/content/blog/2009/06/how-to-contribute-to-mercurial.html	Fri Jan 15 20:14:43 2010 -0500
@@ -77,6 +77,7 @@
 Go ahead and clone it somewhere on your machine (replace `hg-crew` if you
 prefer a different name for the folder):
 
+    :::text
     hg clone http://hg.intevation.org/mercurial/crew hg-crew
 
 It's going to take a little while. Mercurial might be fast but its repository
@@ -102,10 +103,12 @@
 Open a new terminal window while the crew repository is busy cloning. Install
 virtualenv in the usual Python fashion:
 
+    :::text
     sudo easy_install virtualenv
 
 Now install the [virtualenvwrapper][] tool:
 
+    :::text
     sudo easy_install virtualenvwrapper
 
 This is a nifty little shell script that makes working with virtual
@@ -113,6 +116,7 @@
 it into your `~/.bashrc` or `~/.bash_profile` file, as well as choose a place
 to stick the environments themselves:
 
+    :::bash
     export WORKON_HOME=$HOME/lib/virtualenvs
     source /(path to python)/bin/virtualenvwrapper_bashrc
 
@@ -123,6 +127,7 @@
 wherever Python is installed on your system. If you're not sure, here's a
 simple, slow, and horribly inefficient but effective command to figure it out:
 
+    :::text
     find / -name 'virtualenvwrapper_bashrc' 2> /dev/null
 
 Once you've got the necessary lines in your `~/.bashrc` you can close that
@@ -162,6 +167,7 @@
 easily. Modify the `.hg/hgrc` file inside that repository (*not* your
 `~/.hgrc` file!) to look like this:
 
+    :::ini
     [paths]
     default = http://bitbucket.org/(username)/(repo name)/
     crew = http://hg.intevation.org/mercurial/crew
@@ -178,12 +184,14 @@
 
 Make sure you're in your local crew repository, and run:
 
+    :::text
     make local
 
 This will build Mercurial from the source files. It should finish fairly
 quickly. Once that's done, run the tests to make sure everything is working
 correctly:
 
+    :::text
     make tests
 
 Those will take a long time to run. While you wait, move on to the next step.
@@ -195,6 +203,7 @@
 to use for testing your changes to Mercurial. First you need to create it, so
 open up a new terminal window and run:
 
+    :::text
     mkvirtualenv hg-dev
 
 You can name it something else if you don't like `hg-dev`. Notice how your
@@ -204,12 +213,14 @@
 Creating the environment automatically puts you into it for that shell
 session. To get into it in the future you'll use:
 
+    :::text
     workon hg-dev
 
 Now you need to link the Mercurial libraries you're going to change to this
 environment, so you can use it to test your code. Run the following three
 commands:
 
+    :::text
     ln -s (full path to crew)/mercurial $WORKON_HOME/hg-dev/lib/python2.6/site-packages/
     ln -s (full path to crew)/hgext $WORKON_HOME/hg-dev/lib/python2.6/site-packages/
     ln -s (full path to crew)/hg $WORKON_HOME/hg-dev/bin/
@@ -280,6 +291,7 @@
 Before you go off and submit a patch, you need to make sure it works with the
 current tests. You can run the tests by going to the repository and using:
 
+    :::text
     cd tests
     python run-tests.py
 
@@ -288,6 +300,7 @@
 tests. That's alright, but you'll need to fix them to reflect your changes.
 The simplest way to do this is to use the `--interactive` flag:
 
+    :::text
     python run-tests.py --interactive
 
 Using `--interactive` will prompt you each time a test fails and ask if you
@@ -331,16 +344,21 @@
 takes care of the formatting for me. To enable and configure it you'll need to
 make some additions to your `~/.hgrc` file:
 
-    :::text [extensions] hgext.patchbomb =
+    :::ini
+    [extensions]
+    hgext.patchbomb =
     
-     [email] method = smtp from = Your Name <you@yourdomain.com>
+    [email]
+    method = smtp from = Your Name <you@yourdomain.com>
     
-     [smtp] host = smtp.youremailhost.com username = yourusername tls = True
-    
-    You'll need to tweak those settings with your own email address, mail
-    server, and so on. Once that's done, you can have patchbomb package up
-    your changes and email them out:
+    [smtp]
+    host = smtp.youremailhost.com username = yourusername tls = True
 
+You'll need to tweak those settings with your own email address, mail server,
+and so on. Once that's done, you can have patchbomb package up your changes
+and email them out:
+
+    :::text
     hg email --rev (your first revision):(your last revision)
 
 The command will guide you through filling out some more information, and then
diff -r ce99be93f9c9 -r a6628e0d5710 content/blog/2009/08/a-guide-to-branching-in-mercurial.html
--- a/content/blog/2009/08/a-guide-to-branching-in-mercurial.html	Fri Jan 15 20:04:42 2010 -0500
+++ b/content/blog/2009/08/a-guide-to-branching-in-mercurial.html	Fri Jan 15 20:14:43 2010 -0500
@@ -77,6 +77,7 @@
 The slowest, safest way to create a branch with Mercurial is to make a new
 clone of the repository:
 
+    :::console
     $ cd ~/src
     $ hg clone test-project test-project-feature-branch 
 
@@ -134,6 +135,7 @@
 
 An example of this method with three branches would look something like this:
 
+    :::console
     $ hg clone http://server/project-main project
     $ cd project
     $ hg pull http://server/project-branch1
@@ -180,6 +182,7 @@
 
 The next way to branch is to use a bookmark.  For example:
 
+    :::console
     $ cd ~/src/test-project
     $ hg bookmark main
     $ hg bookmark feature
@@ -255,6 +258,7 @@
 
 To create a new named branch:
 
+    :::console
     $ cd ~/src/test-project
     $ hg branch feature
 
@@ -377,6 +381,7 @@
 push/pull only a single branch with Mercurial you can use the `--rev` option
 (`-r` for short) and specify the tip revision of the branch:
 
+    :::console
     $ hg push --rev branchname
     $ hg push --rev bookmarkname
     $ hg push --rev 4