The word processor has been a part of computing platforms since the earliest days of the home computer; I’ve used a number them over the years, including PFS-write on the Apple IIc, WordPerfect (both DOS and Windows versions), Microsoft Word, OpenOffice, and AbiWord.\n<\/p>\n
\nA couple years ago, though, I got frustrated with the whole word processor concept, and found a way to create text documents that works a lot better for me. This article aims to describe the how and why of that move, for the benefit of others who find they just don’t like working with word processing software.\n<\/p>\n
<\/p>\n
\nI’m sure someone reading this article is completely baffled at this point about what sort of problems I could possibly have with word processors. I’ve met many people for whom a computer without Microsoft Office is practically a paper-weight, and for whom the primary purpose of a computer is the creation and modification of Office documents. For such a purpose, the word processor is generally accepted as a proven, highly evolved, and time-tested tool.\n<\/p>\n
\nWithout dwelling too much on the negative, I’ll go through some of the issues I have with word processors that eventually led me to look for an alternative way of creating documents.\n<\/p>\n<\/div>\n
WYSIWYG1<\/a><\/sup> editing has been a standard method of document creation since the early 1990s. Most people appreciate being able to directly work on the “end product” without going through some meta-data middleman or having to imagine what the end product could look like.\n<\/p>\n \nI’ve discovered that I don’t like it.\n<\/p>\n \nYou see, WYSIWYG assumes that you know or care what you’re going to “get” in the end. Not every piece of text (nor even a significant minority of them) that I write is destined for paper. In fact, often it’s not clear what the end format of a document is going to be. It might get rendered to PDF for printing, or HTML for blog or online help content. It might end up as part of a plain text README file bundled with source code, or it might just stay on disk as-is for me to refer to at a later time.\n<\/p>\n \nEven when a document is<\/i> bound for print, my brain doesn’t need the ever-present distraction of “what you get”. I’ve found myself getting derailed from writing for hours looking for the perfect font for level three headers, or tweaking the perfect margin between paragraphs. Taking away this capability means I can focus on content and organization, rather than a final appearance which may not actually be the final appearance.\n<\/p>\n \nAside from the distraction, though, WYSIWYG requires that a program do a whole lot of stuff “behind the scenes” to try to make editing as simple and straightforward as if you were working on the physical printout. Sometimes it doesn’t do what you want, or sticks things in there you didn’t ask for2<\/a><\/sup>. I do not, in general, like programs that refuse to let me get under the hood, see what’s really going on, and edit the underlying nuts and bolts of my data directly.\n<\/p>\n<\/div>\n<\/div>\n When I compose a significant amount of text, I like to keep my hands on the keyboard. Most modern word processors have some keyboard shortcuts, but they also seem to assume that you’re perfectly happy grabbing for the mouse when you need to do some moderately advanced editing routine.\n<\/p>\n \nIt may seem trivial, but for me it’s highly non-ergonomic to constantly bounce between keyboard and mouse, especially when the mouse is a touchpad on a laptop. Having to do it repeatedly is an exercise in frustration.\n<\/p>\n<\/div>\n<\/div>\n We finally, as of a couple years ago, have some open standards in the document arena; even so, modern word processing documents are so complex that the standards don’t seem to be able to accomplish what they fundamentally set out to do: enable people to exchange documents between different editors without losing or corrupting any work. That’s still pie in the sky.\n<\/p>\n \nI’ve lost no small amount of work to the changing tides of file formats over the years. Perhaps those days are behind us now, but with all the platform shifts going on right now, having your documents stuck in a format that only reliably opens in one program, which only runs on a certain platform, has got to be an inconvenience now and then.\n<\/p>\n<\/div>\n<\/div>\n The older I get, and the more I need to get done, the less tolerant I am of software that wastes my time. When I need to work on a file, I want to go from desktop to blinking cursor in as little time as possible. Not after you’ve displayed your splash screen, read half a gigabyte off the hard drive, and painstakingly styled a bunch of widgets that I won’t even use.\n<\/p>\n \nNot only that, but I’ve grown to be an old-school Linux user; I am never more than a keystroke or two from a BASH prompt, and I am just as comfortable with grep<\/i> and find<\/i> as you likely are with mouse clicks.\n<\/p>\n \nIf I need to find a snippet of information in a file, I don’t want to have to load up some massive monolithic application just to get a piece of text. I want to grep for it from a prompt and move on. That’s and example of my workflow; it may be odd, but there you have it. Word processing applications don’t fit into that workflow.\n<\/p>\n<\/div>\n<\/div>\n If you aren’t an Emacs user, you might not understand; but once you start using Emacs, you eventually want to migrate all your computing tasks to it. It’s an amazingly powerful editing environment, and as you begin to learn and use its more advanced editing features, you increasingly feel their absence in other environments.\n<\/p>\n \nIn addition, a lot of the documents I have to prepare are technical documentation for code that I’m writing. It’s nice to be able to do this in the same editor that I’m writing my actual code in, and not have to bounce between two big bloated programs with different behaviors and keyboard shortcuts. I can use one program for everything I write, be it code, web pages, technical documentation, song lyrics, blog articles, etc.\n<\/p>\n<\/div>\n<\/div>\n<\/div>\n \nSo maybe by now you’re wondering, if I don’t use a word processor, how do I compose documents? In a word: markup.\n<\/p>\n \nIn a few more words, I use my \u00fcber-powerful text editor to compose documents in a lightweight markup language, which I can easily render to any end-format that I need.\n<\/p>\n \nIf that sounds difficult, it’s not. In fact, if you pick the right combination of text editor and markup language, it can be amazingly ergonomic and productive.\n<\/p>\n \nSo let’s take a look at the choices you have with this approach.\n<\/p>\n<\/div>\n Is there really a choice here? You want to use Emacs. Of course you do. OK, well, you don’t have to; but unless your text editor has some special modes for handling your chosen markup language, it’s going to be a bit tedious to do certain things.\n<\/p>\n \nI suppose you’ll realize some of the benefits of the markup language approach even using notepad.exe, but what you really want is a text editor geared at programmers: something that will at least give you syntax highlighting and the ability to run arbitrary shell commands on the current file (for quick rendering).\n<\/p>\n \nI’m guessing you probably have a favorite editor already; but if not, it’s time to go Emacs, my friend.\n<\/p>\n<\/div>\n<\/div>\n Here’s where you have some choices to make. I haven’t tried every markup language under the sun, but I’ve been through a few. Here are my impressions of some of the ones I tried.\n<\/p>\n<\/div>\n When you hear “markup”, probably the first thing you think (if you actually know what common computing acronyms stand for) is HTML; or, if you’re a bit more modern and savvy, XML. It’s the world’s most popular markup language, after all; and for a while, I attempted to compose documents directly in raw HTML.\n<\/p>\n \nHonestly, though, HTML is not what you want to use. It doesn’t matter if you’re a web developer extraordinaire who knows w3c specs inside and out, the fact is HTML and XML are equally painful both to type and<\/i> to read in raw format. All those angle brackets, verbose tags, and forward slashes get quickly painful to type, and it’s amplified by the fact that you need opening and<\/b> closing tags.\n<\/p>\n \nThe text itself is quickly buried in a forest of tags, making it difficult to read un-rendered. Overall, despite its widespread popularity, HTML is just not a good markup for writing in.\n<\/p>\n<\/div>\n<\/div>\n Markdown is a popular markup language created mainly for blogging, with the express goal of making it simple to generate HTML with a simple, readable syntax. So for example, if you had a bit of HTML like this:\n<\/p>\n This list is SUPER<\/em><\/p>\r\n \n…the equivalent Markdown would be more like this:\n<\/p>\n \nAs you can see, the Markdown is much more type-able and readable than the HTML. Run this simple syntax through a Perl script, and you’ve got your HTML. Markdown even allows you to insert raw HTML when its own syntax fails you,\n<\/p>\n \nThe downside of Markdown is that it’s really only designed for writing simple HTML. If you want to generate something else, or have a complex document, you may end up writing a significant amount of HTML (for instance, there’s no canonical way of creating tables in Markdown apart from using HTML tables… which I always found odd, since that’s one of the most painful aspects of writing raw HTML).\n<\/p>\n \nMarkdown is quite popular, though; and for that reason, it was one of the first markup languages I looked at. I didn’t get very far with it, though.\n<\/p>\n<\/div>\n<\/div>\n Restructured Text, or RST, was originally conceived of for the purpose of writing Python documentation; and all of Python’s built-in documentation is now written in it. It shares a lot of syntax with Markdown, but it’s not specifically aimed at generating HTML (thought it often is used that way) and it boasts a few more features. Here’s an example of RST, including a simple table:\n<\/p>\n \nBeing a bit of a Python hacker, and wanting something with some flexibility, I ultimately gravitated to RST and have been using it mostly happily for the last few years. Most recently I was happy to find that github<\/a> will automatically render my RST README files to HTML on my project sites.\n<\/p>\n \nWhere RST started to let me down is in rendering. The tools for rendering RST are a set of python scripts with names like rst2pdf, rst2html, etc. These work decently, but it’s hard to get specific customization of the output without writing your own styles and templates (which is yet another API to learn…). Most of the time I just end up going with the (rather “meh”) defaults.\n<\/p>\n \nThe other area I grew disenchanted with RST about is the tools available. Emacs has an RST mode available (rst.el), but apart from some (incomplete) syntax highlighting and some rendering shortcuts, it doesn’t offer much. Finally, some of the syntax is just a little non-obvious (footnotes and URLs, for example), and I find myself looking it up all the time.\n<\/p>\n<\/div>\n<\/div>\n My current favorite, in which I’m writing this very text, is Emacs org-mode.\n<\/p>\n \nFor the longest time, I thought org-mode was some kind of day-timer facility for Emacs, as that is how it’s often billed. Since I seem to be allergic to any tool which promises to organize and schedule my life, I never quite took to org-mode.\n<\/p>\n \nEven so, I kept hearing and reading about all the cool stuff you can do with org-mode, and got curious; I discovered that org-mode, really, is just a markup language. It’s a very specific markup language for creating organized, hierarchical documents, yet it supports a huge range of features, and one can easily insert snippets of other markup languages.\n<\/p>\n \nIt’s not just a markup language though; it’s also an extensive Emacs mode chock-full of tools to manipulate and use your org-mode documents. It’s got nice features like being able to fold up sections or use includes. It has strong support for meta-data and things like tagging, which is how it came to be used as a scheduler\/calendar application (you can date-tag entries in various ways). The Emacs community seems to have given org-mode a de-facto blessing simply on the basis of the number and variety of tools3<\/a><\/sup> available for it.\n<\/p>\n \nOrg documents can be exported to (reasonably clean) HTML, or (by way of LaTeX) PDF files. I found the latter to be a little troublesome at first, since the default LaTeX template is ugly like the 1990s; but after applying some tweaks and copy-pasta’ing some alternate styles from various emacs blogs, I was able to make a default style that I liked.\n<\/p>\n \nThe cons of org-mode are that some things require the use of metadata calls and other non-obvious syntax; I had to learn a bit more about LaTeX than I originally wanted to so that I could render PDFs the way I wanted. I think RST is a bit cleaner in some situations, such as quoting blocks of code.\n<\/p>\n \nOf course, outside of Emacs, I imagine that editing org-mode markup is rather a drag, and probably not supported at all. So if you’re not an Emacser, it’s probably not going to make your short list.\n<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n \nRegardless of the chosen markup, the advantages of this method are mostly the same; in no particular order:\n<\/p>\n \nMost importantly, I enjoy writing now more than I ever did in my word-processor days; and that means more writing. And that, after all, is the point, no?\n<\/p>\n 1<\/a><\/sup> “What-you-see-is-what-you-get” – do I really need to spell that out in this day and age? Better safe than sorry, I guess.\n<\/p>\nThey have serious mouse dependency<\/h3>\n
They have problems with File formats<\/h3>\n
They’re bloated, and command-line un-friendly.<\/h3>\n
They aren’t Emacs<\/h3>\n
The alternative<\/h2>\n
Text editor<\/h3>\n
Markup Language<\/h3>\n
HTML\/XML<\/h4>\n
Markdown<\/h4>\n
\r\n
My super list of superness<\/h1>\r\n
\r\n
\r\n
\r\n# My super list of superness\r\n\r\nThis list is _SUPER_\r\n\r\n+ First List item\r\n+ Second List item\r\n + First sublist item\r\n + second sublist item\r\n+ Third list item\r\n<\/pre>\n
Restructured Text<\/h4>\n
\r\n==============================\r\nThe World's best document ever\r\n==============================\r\n\r\nChapter 1: Cool table, man\r\n==========================\r\n\r\nThe Characters\r\n--------------\r\n\r\n===== ===========================\r\nName Information\r\n===== ===========================\r\nBob Crazy wearer of pants\r\nRob Bob's brother\r\nAmy Odd nose-haver\r\nJed Guy with old-fashioned name\r\n===== ===========================\r\n\r\nThe Plot\r\n--------\r\n\r\nLots of **stuff** will happen to \/\/people\/\/ in this crazy crazy story.\r\n\r\n<\/pre>\n
Emacs org-mode<\/h4>\n
The advantages<\/h2>\n
\n
Footnotes: <\/h2>\n