MoinMoin for notebook-wiki (and WordPress, you are trying the patience of my affections)

For two days short of a full calendar year I have been keeping a wiki of my computing notes. A wiki, a lightly organized website structure, is much better than a nest of files in subdirectories if you are trying to keep track of what you have learned and accumulate a record of your experiments and experience. And running it on a server means it is available to you more or less everywhere.

I have been using MediaWiki, the software that powers Wikipedia. I know it pretty well, having fiddled with Wikipedia ever since it emerged from the miasma of unrealized memes. But this year of MediaWiki has been frustrating. The application is good for mixing markdown with HTML — markdown is very low maintenance and HTML is helpful when you want fine control of formatting or to include something from a website — but MW’s brand of markdown sometimes has small problems (for instance, numbering of an ordered list sometimes resets when a line of “preformatted” content is interspersed among the numbered items). And a whole MediaWiki site is not so easy to back up — the simplest thing is to dump the whole MySQL database, but then that’s a large file to deal with every day.

Finally this morning I broke down and installed MoinMoin, and transferred my whole MediaWiki database into it. MoinMoin isn’t as good with HTML as MediaWiki is, but its brand of markdown is simpler than MediaWiki’s. I like the fact that each page is stored as a flat text-file, meaning that backup with mercurial is very efficient — only individual diff patch-files are pushed to server.

I dare say markdown will replace HTML in many environments.

Best of all, MoinMoin looks pretty good in w3m, my text-only browser of choice.


For a while it didn’t look as though I would be permitted to post this. WordPress has drastically redone its software, and I could no longer see most of what I had written; nor could I preview my text or assign categories to it. Beside the non-functional text field there was a little remark: “Blogs are not just for long posts. Why not post a photo or video instead?”

I chose WordPress over other sites because I liked their software; it seemed the best tool for what I wanted to do. If I stop liking it, the whole relationship will be in danger. I don’t mean to sound like a pretty girl with too many suitors, but no company should take my patronage for granted. I don’t need a slick interface — not at all — and I don’t need social media. If that’s all you have for me, it’s “goombye pliz”.


(grumble, grumble, a little later)

After posting the abortion of this note as a “quotation” (since WordPress’s parsers determined that there was no content in the original “text” format), I later became able to edit it in the familiar interface, with the minimum functionality I require. What a mess. If your product works, leave it alone, people.


Yes, I said text-only browser. W3m, made in Japan, the homeland of craftsmanship. I am a man of command-line temperament and of words written and then revised and then revised again. Spare me your sticky GUI; spare! o spare me your tweets and friending and live webcam feeds, and let me type what I have to type and have it read by those who have the patience to read.

Classical Chinese syllabus posted; using Landslide for markdown-to-HTML5

In my teaching this year, I’m going to avoid course management software like Courseworks and Blackboard entirely, and build my own little password-protected site, for the practice.

I’ve posted the syllabus publicly as HTML5, the first time I’ve attempted to use that format. I constructed it using the wonderful Markdown language, which I converted to HTML5 using Landslide. Landslide is very convenient and (in v. 1.0.1) was easy to install and operate. I also tried using Pandoc (v. 1.5.1.1, via apt-get on Ubuntu 10.04; newer versions have unworkable dependencies) with the -w slidy option, but Landslide looks much better, at least with the default options.

Two small matters in Landslide v. 1.0.1, which I’ve reported as issues:

  • Not all of the functionality is described in the README file; .qr, for example, is currently only described in one of the sample files (https://github.com/adamzap/landslide/blob/master/samples/example1/slides.md).
  • Although ordinary Chinese text in Unicode displays correctly, high codepoints (represented in UTF-8 as surrogate pairs) do not. High codepoints are rare, but the failure of software to handle them correctly is not.

Thanks to Norm Kabir and WES Skeith for the inspiration of their own markdown-based course materials.

LaTeX and electronic documents

The current issue of TUGboat (32.2, 2011), the Communications of the TeX Users Group, has eight papers in a section called “Electronic Documents,” dealing with various issues affecting the relationship between LaTeX and the latest fashions in on-line publishing and mobile devices. The ePub format, standard on most e-readers, remains a significant rival to the dominance of PDF, widely used for long-term document storage, and several of the articles address the challenges ePub presents.

All are worth reading; I single out these two as especially useful:

A third noteworthy paper is Axel Kielhorn’s “Multi-target publishing” (based on a German original, also 2011), which describes pathways from LaTeX to PDF or ePub output by way of John Gruber’s Markdown language (currently at http://daringfireball.net/projects/markdown/). The chief element of these pathways is Pandoc, on which see http://johnmacfarlane.net/pandoc (accessed 20120107); the main Github repository is currently at https://github.com/jgm/pandoc (accessed 20120107).