Eight Questions for [not]Klaatu

Welcome to this edition of Eight Questions For…, where I pick the brains of plain text enthusiasts from around the world and around the web. This month, I’m chatting with talented internet man of mystery [not]Klaatu.

[not]Klaatu describes himself as a nerd who stumbled into computing by way of dropping out of film school. His interest span the artistic and the techie — he writes, podcasts, programs, and tries to stay out of noticeable trouble. At the core of everything he does, though, is plain text. He gets bonus points for mainlining DocBook (an old favourite of mine).

Let’s hear from [not]Klaatu:

When did you start using plain text?

I grew up with plain text because I didn’t know the difference, but eventually I unfortunately discovered word processors and started using those. It didn’t take me too long to see weaknesses in word processors: they were always trying to fix things for me, and no matter what I did, it seemed their formatting was strangely impermanent. I felt it was an uphill battle, trying to format what I wanted my final product to look like, but at the same time edit the
copy to get the words right. Without knowing how to express it, I’d discovered that I needed to separate content from style.

It wasn’t fun at the time, but I’m very lucky to have suffered a few catastrophic file corruptions, in which I lost a bulk of what I had produced as a teenager. Around the same time, the company that made the word processor application also ceased support for it, and so I finally realised that plain text just plain made sense.

Why did you start using plain text?

Aside from finding plain text better at its job than word processors are at theirs, I learnt at my first tech job that plain text could be managed like code. This appealed to me.

I also found that plain text, as long as it is structured in some predictable way, could be styled in any way I wanted, using simple custom scripts or other applications. And even after styling, I’d still have the plain text source. It was the best of all possible worlds.

If that wasn’t enough, I also have a few blind friends who probably couldn’t use computers if it weren’t for plain text: screen readers (a kind of software) can’t see binary objects, so the computer just reads out the plain text strings associated with objects, which allows a blind user to navigate an interface without seeing it.

What do you use plain text for?

Basically everything, honestly.

When I write, I write in Docbook, an XML schema (it’s like HTML, but with more tags to remember). With my sources saved as XML, I’m able to apply custom XSL (think of it as the CSS of the XML world) styles and
export to EPUB (the HTML-based open source ebook format) or to HTML or even to something screwy like .docx or PDF. I script this process with GNU Make.

When I draw something, I frequently use Inkscape, which saves to SVG. SVG is actually an XML schema, so even my graphic work technically ends up as plain text.

When I make music, I use Qtractor and a bunch of plugins. When I stop for
the day, I use aj-snapshot to take a plain text snapshot of my
session so I can quickly resume work later.

Of course, programming, whether it’s Python or Lua or C++ or Java, happens in plain text. And HTML and CSS and Javascript and PHP. It’s all just text.

And I use Linux exclusively, so all of my user preferences and many of my daily tools are written in plain text, so I can edit them from anywhere with or without special applications or even Linux itself.

There are some things I do on a computer that don’t involve plain text, but I’d say it was less common than the things that do.

What keeps you using plain text?

Flexibility and parseability.

Plain text isn’t married to a specific set of tools, much less to a specific platform. You can always turn it into something more exciting after the fact, but your source should be plain text. It’s the vulgate of computers. It’s simple, and it’s harder for something simple to fail the way over-engineered, needlessly complex systems do.

In addition to that, text can parsed with lots of amazing tools. If you’re a geek, you can do amazing things with a few clever grep and sed commands. If you’re not interested in juggling text that way, then there are tools like pandoc and Docbook and Sphinx and Asciidoc that make it easy to reliably produce amazing documents.

Do you use any markup or formatting languages? If so, which ones and why?

I use Docbook because it’s explicit. Docbook was the first markup language I learned, because the Slackbook was written in Docbook and I wanted to build the latest version of it from its source code. Next thing I knew, I was using it on a daily basis for my own work, and then I got hired at a company to work in Docbook all day,
and eventually it just became second nature.

I did try others but I prefer Docbook because it lets me be specific about the structure and semantics of my text. For me, tagless structured text fails at making markup natural. Every time I use Markdown, I have to resort to HTML to get around infuriatingly silent parser failures, and when I use others like Sphinx or Asciidoc, I end up having to find work-arounds to achieve the style I want. When I work in Docbook, I’m able to tag text for what it is, and then apply styles according to those tags when I’m ready to style.

That said, Docbook is cumbersome for some things, so I do use
CommonMark, not necessarily because I like it, but because it’s a popular form for structured text, and that’s certainly better than unstructured text, or having 100 different structures. And CommonMark does fix many of the problems in pure Markdown.

What are your favourite plain text tools or applications?

I use GNU
Emacs for almost all text, whether I’m writing an article or a book or a config file or software.

Like most Emacs users, I have an extensive .emacs file, so my version of Emacs is uniquely customised for how I work. That’s the advantage of using an editor that is also its own interpreter.

I use nxml-mode when I write in Docbook, and I highly recommend that for anyone looking into Docbook. This mode lets Emacs catch a lot of
XML errors that you wouldn’t otherwise find out about until processing
time.

For processing my XML into pretty deliverables, I mostly use xmlto,
xsltproc, and fop. Xmlto is a script that converts XML to common
formats like HTML, which I bundle up as an EPUB using Linux’s zip
utility. For PDFs, xsltproc applies XSL styles and then fop (from the
Apache Foundation) transforms it to PDF.

When I’m too busy or too lazy to bother styling my own XML, I use
pandoc, which converts nearly anything to nearly anything else. It’s a
big tool, but one that no plain text user should be without.

Is there one tool that you can’t do without?

Is there anything you can’t do with plain text?

Personally, I can’t think of anything.

I’ve heard that plain text isn’t great for huge data sets, because you end up just scrubbing every single string for a match. For instance, you can encode graphics using plain text, but you just wouldn’t do it. That’s why applications, like The GIMP, use binary file formats. You wouldn’t want to wait for a 4k photograph to be parsed from its plain text description.

If you want to learn more about [not]Klaatu and what he does, here are some good places to start:

For a sample of Docbook, XSL, and a functional build workflow, check
out DM Schema source
code, which serves as the source for an implementation of the
official DMs Guild template for Dungeons & Dragons
adventures.