Markdown for Writing Projects

I use Markdown for writing because it’s simple, vendor neutral, and easy to process. Using Markdown, I’m not locked into a particular word processor or proprietary format. I work with text and text is awesome. I want to describe how I use Markdown to write and generate artifacts such as html, pdf, and various e-book formats like ePub.

The writing solution I wanted had these requirements:

  • I want to edit in plain-text, Markdown
  • I want to control how the HTML looks  by writing the CSS myself
  • I want the PDF to look like the HTML
  • I want the e-book format to look like the HTML and PDF
  • I want the HTML, PDF, and e-book formats to be built from the Markdown source, automatically
  • I want to edit remotely on my iPad and have my local and remote work synchronized
  • I want to retrieve past revisions in case I paint myself into a corner and I need to get back to the place I was before

I’ll write a few posts over the course of the next few weeks that will serve as a general introduction to how I used MultiMarkdownmakegit, and Dropbox to address these requirements. For now, let’s talk about Markdown.

Why Markdown?

Most people I know are already well versed in the beauty of markdown and plain text editing. Markdown is used all over the place. Github uses their own flavor to power all of their README’s, messages, comments, and more. There is blogging software that uses it. Lots of editors can do some basic coloring and bolding of markdown text to make it look pretty without a full conversion to HTML markup. It’s also just nice to read as plain text, since being readable as plain text is one of the primary features of Markdown.

You may ask what software is available to convert the plain-text markdown into something fancier. There are tons of options here. Here are just few:

  • Jekyll – Takes markdown files and can generate a static website, like a blog
  • Marked – A Markdown editor with HTML preview and PDF generation capabilities
  • Scrivener – A full-fledged writers tool that uses Markdown, manages characters, to-dos, scenes, etc.
  • Byword – A simple iPhone/iPad/Mac editor
  • TextMate – An awesome text editor for the Mac. Unlike vim, easily allows wrapping margins.

Oh how I wish WordPress would allow me to use Markdown as the native editor format! There is wp-markdown plugin, but I haven’t had the guts to try it out yet. I’m so afraid of being disappointed. It works by taking Markdown and converting it to WordPress HTML and it converts it back to Markdown when you edit a post. That scares the crap out of me.

Most of the software options listed previously allow you to write in Markdown and they can convert to something like HTML or a PDF with some canned stylesheets. And they probably do this through the GUI. For my purposes, I wanted to use TextMate and I wanted to write the stylesheet myself. I originally tried to use vim as my Markdown editor, but I found out that Vim sucks noodles at Markdown editing.

I didn’t want to use a complex tool that has a lot of features. Scrivener might be nice, I never tried it, but it looks awfully complex. I didn’t want to use a GUI. I didn’t want to pull down a menu to generate my HTML. I wanted to use the command line because the command-line is awesome. In a nutshell, I wanted Markdown to be my code and I wanted a build system that produced my programs: the HTML, PDF, and e-book formats.

I wanted to us make to see that my Markdown files are modified and have my HTML generated automatically. I wanted to write chapters as individual Markdown files and have them auto-magically aggregated into a book a post-process. Just like a linker!

In my next post, I’ll talk about MultiMarkdown and why it’s awesome and how I use it to generate HTML with my own CSS. I even tricked the HTML generation to insert javascript to produce automatic hyphenation since hyphenation is still something that HTML5/CSS3 don’t seem to do well in most browsers I tried.

Private git repos

So I began setting up some private git repos on my own web server. Lots of folks would say to use github for that, or bitbucket. The repos need to be private, mainly because they are my writing projects and works in progress. As you probably know github charges for private repos. Butbucket offers them for free, but I still chose to store these on my own server. Mainly because there will be zero collaboration on these writing projects and github and bitbucket are awesome at collaboration around repos. If it were code, and I’d want people to fork and stuff, things would be different.

To do this, I use a script I put together from forgotten sources on the internet (sorry). The script is written in bash and I run this on my remote host, which I have access to via ssh. Here is the script:

newgit()
{
    if [ -z $1 ]; then
        echo "usage: $FUNCNAME project-name.git"
    else
        gitdir="/home/$USER/repos/$1"
        mkdir $gitdir
        pushd $gitdir
        git --bare init
        git --bare update-server-info
        touch git-daemon-export-ok
        popd
    fi
}

The key to this is the git --bare init and git --bare update-server-info. The --bare option makes sure that the root of the repo looks like what you would normally see in the .git directory at the root of every repo. It doesn’t contain the current branch’s files like a normal git repo does. This is the ideal way to configure a remote origin you use as the central repo (if your git workflow cares about a central repo).

Once that’s created, I installed my ssh keys under a new user I created on my remote server, called gitsrc. On my Mac, I configured an ssh alias via .ssh/config as follows:

Host gitsrc
HostName primordia.com
User gitsrc
IdentityFile ~/.ssh/id_rsa_disven

This allows me to ssh via a simpler syntax. Instead of saying ssh -i ~/.ssh/id_rsa_disven gitsrc@primordia.com, I can simply say ssh gitsrc.

On my local machine, I navigated to the root of each writing project and issued the standard git initialization commands:

git init
git add .
git commit -m "Initial commit"

Then I added the remote origin:

git remote add origin gitsrc:repos/test.git

I could also have been more verbose and said gitsrc@primordia.com:repos/test.git, but the config file allows me to be more succinct so that’s what I did.

That’s all I have for you.