Home

Compsoc Lightning Talks

  • Nov. 24th, 2007 at 2:25 PM
lens

If you’re not a massive nerd, I was just shown a joke which you might enjoy more than the rest of this post:

What do you call the blood that comes out when teenagers cut themselves?
Emoglobin.

On Thursday, Compsoc had a lightning talk session. Four people spoke:

  • Andrew, the President, spoke about LastGraph (slides);
  • I talked about ikiwiki, which we use behind the scenes for Compsoc’s website;
  • Luke gave a talk about virtual worlds in general and Second Life in particular, and gave a demo;
  • David spoke on “Windows Vs. Linux: Which Is Better?”, featuring a hilarious sketched-and-scanned graph which I would like a copy of.

I’m more impressed with Second Life than I thought I’d be. If only my laptop were speedy enough to run the thing, I’d take a look. (I tried to run it on my i855; the CPU pegged itself then everything died. Hard reset time!) I like the idea of a scripting language where everything is a state machine. It’s a bit of a shame that the only way to get code into or out of Second Life is to copy-paste between the built-in Notepad-alike editor and your proper editor of choice, which presumably does new-fangled things like “version control”. Oh well.

In case you care what I said about ikiwiki, I stuck my slides on the ’tubes. I’ve figured a few things out since the talk, such as how to get post-commit hooks working in Mercurial. Dom has some plans to add branching to Ikiwiki, so that you can make a test instance of the wiki to play with a new plugin just by making a new branch in svn or whatever. I like this idea.

S5 is pretty slick. I’d not used it before. (I didn’t actually use it directly, though: I relied on Pandoc to convert a file written with [Markdown] into an S5 slide show.) Anyway, there’s a lot to be said for having a slide show that you can just fire up in any web browser. (Except Andrew’s Konqueror apparently didn’t understand it. I wonder whether this is S5’s fault or Pandoc’s fault.)

Pandoc is a highly slick piece of software. It converts from any of Markdown, reStructuredText, HTML or LATEχ to Markdown, rst, HTML, LATEχ, man pages, ConTeXt, DocBook, RTF, or S5. It does all kinds of nice things along the way like curlifying quotes, making proper en-dashes, rendering LATEχ expressions as images so you can use it inline in Markdown and have it exported properly as HTML, and so on. It turns out to be a better Markdown processor than markdown itself, and supports extra things like tables, footnotes and so on. It turns out that the output from a practical I finished today was very nearly valid Pandockian table markdown, so I got a well-formatted project report pretty much for free. Oh, and for extra winning, it’s written in Haskell. I like the idea of being able to write man pages and documentation in something other than raw groff or DocBook XML.

I think the lightning talk format worked pretty well for Compsoc; it strikes me as a good way to get people involved. Nice work, committee!

HTML email, mutt, and Markdown

  • Feb. 18th, 2007 at 10:51 PM
lens

(Yes, this is another technical post. Sorry, [info]embitteredpoet. For those of you uninterested in the rest of this post, take a look at a stuffed squirrel riding a go-cart for sale on eBay.)

Like most geeks, I am not a big fan of HTML email. This is partly because my email client is mutt, which is text-only, and partly because HTML email tends to be full of mad flashing things, images and other badness.

When I write email, I tend to use text formatting similar to that of Markdown. By design, Markdown source is human-readable, so it's a pretty sensible set of conventions to use for emphasis, links etc. in plain text. This works pretty well for people with similar tastes in email clients, but is suboptimal for people who use things capable of rendering rich text. Ideally, those people would see the text as rendered by running it through the markdown command — that is, as HTML. One way to accomplish this would be to write plugins for every graphical email client under the sun; the other, more practical way is to render it before I send the email and send HTML email.

I'm instinctively offended by the suggestion, but neither of my reasons for hating HTML email apply here: I'd still send the Markdown source as the plain text version, and the messages wouldn't be any more full of crap than they are in plain text. I think I should duct tape this functionality onto the side of mutt. My Googlings have not found anyone else who's done this before, but I figure I should check: dear Lazyweb, have you seen scripts to do this that I could use rather than writing my own? I'd probably write a script that acts as /usr/sbin/sendmail as far as mutt is concerned, but which checks the plain-text bit for Markdown syntax and generates the text/html part if necessary.

(Also, I should make pyljpost.vim understand Markdown, but that involves learning Python.)