eating cucumbers without permission...

The standard way of marking up code blocks is to use the <code> and <pre>. The former indicates that it is code; the latter that it is preformatted. Without the <pre>, whitespace gets lost, ruining–for example–function indentation. This is fine until you post a very long line, which–being preformatted and not following normal word-wrap rules — doesn’t fit on the page.

Normally I wouldn’t care that it happened here, because as far as I knew, lines would just extend further out into the white. But then I realized that IE stretches the content div, displacing the sidebar. Horror!

There are a couple of solutions, but the prettiest by far is a trick invented, as far as I know, by Simon Willison. A code block can be presented as an ordered list of code spans, with the added usefulness of line numbers. More to the point, code spans will happily word-wrap.

Thus I present the Codeolulator, a plugin for WordPress 1.5. (It will not work with 1.2.)

The name, I agree, is unforgivable: I was thinking about Marvin the Martian’s “Illudium PU-36 explosive space modulator“, and <code>-<ol>-ulator was so terrible a pun that I could not resist. I expect no forgiveness.

Existing solutions weren’t quite right for my workflow. Because I write in Markdown [see the page-widening post in question in Markdown format], some automatic processing is necessary–the Markdown filter turns innocently indented blocks into <pre><code>. As a result, the filter either has to replace the indented text or the formatted code block. I chose the latter, since it’s easier to match with a regular expression.

A popular approach is to use a script to import text files for display, then have a link at the bottom to view the script on its own. Dunstan Orchard’s use of this on his blog was the first place I ever saw the <code><ol> magic. Aaron Schaefer’s Code Viewer plugin, which I stole some code from, is an easy way to implement this in WordPress.

It’s a good idea: the <ol> voodoo does inhibit usability to some degree, because copy and paste doesn’t always work right. Firefox, for example, insists on copying hashes as list markers, and they need to be deleted before the code can be used. With a plaintext alternative, this is not a problem. One oft-repeated benefit is that it saves time because a code snippet can be updated once and shown on multiple pages, but that’s certainly of no use to me.

Using external files is horribly wrong for my workflow, mainly because it’d interfere with how I write — i.e., it’s easier to paste a code snippet into this window than make a new text file, and that’s not even touching on the requirement to fire up an FTP client to upload the damn thing. There are also some complications with Markdown and other plugins.

The Codeolula- I’ll just call it “the plugin” from now on–the plugin instead grabs all <pre><code> blocks and replaces them with their <ol> equivalents. This adds to the already-ridiculous amount of post-processing the text goes through, but it does look very pretty.

Since I still wanted the plaintext alternative, I added an option to generate each one automatically. In much the same way as appending “/text” to the end of a rephrase.net post URL should provide the Markdown version, appending “/code/1” should return the first code snippet, “/code/2” the second, and so on. The plugin adds the rewrite rules.