Over the past several months, I did one of the hardest things for a professional writer: I switched to a new word-processing application. This is the third time in my ten-year writing career that I’ve done this. Shortly after leaving the lab, I migrated my work from a “borrowed” copy of Microsoft Word (The Worst Word Processor Ever Created) to the vastly underrated AppleWorks application. When Apple abandoned that product, I moved to the supremely elegant Nisus Writer. I’ve heard that for some writers, this application was their main reason for buying a Mac. While I have other excuses, I can understand that thinking perfectly. From its uncluttered, easily configurable menus and tool drawer to its open, nonproprietary file format, Nisus is truly a writer’s tool.
If I were not such an extreme geek, I would have stuck with that decision, and I still recommend Nisus Writer to aspiring and practicing journalists who aren’t especially technical. Besides its aesthetic advantages, having all of your notes and past stories in text-based files (specifically Rich Text Format, or RTF) ensures that your archive will remain accessible for years to come. You can’t say that about many other formats.
About a year ago, though, I started to re-learn computer programming after a 20-year hiatus, and it changed my perspective on “word processing” completely. You wouldn’t know it to read their emails, but in their regular work, computer programmers are the most diligent copyeditors on the planet. As a result, they’ve developed text-handling systems that make even an elegant word processor like Nisus Writer look like a dull #2 pencil. If you’re a technically-minded writer, especially if you work for “new media” outlets on the Web, keep reading.
A modern application, such as a Web browser, consists of two types of files: source and compiled. The compiled program is what most of us want; it’s the set of machine-readable instructions that tell the computer what to do. Indeed, most commercial software is only available in compiled form. But programmers don’t write compiled code. Instead, they work with source code, a series of text files containing human-readable, or at least programmer-readable, versions of the instructions that will get turned into the final compiled code.
The source code for an application can easily run to hundreds of thousands of lines of text, and it’s typically spread across dozens of separate files. Programmers have to be able to keep all of that text organized, search through it in myriad ways, edit it, and coordinate their work with their colleagues. It’s like writing and editing a very large collaborative book, except that books are much more tolerant of errors – a single typo in the source code of a program, even a missing semicolon, can derail the entire application. To handle this mammoth task, they turn to text editors. The best programs in this class are all free, and they’re worth a look for anyone who deals with complex texts.
In the photo below, for example, you see a screen capture from a recent project I worked on for the New York Academy of Sciences. Inside the window, I’m working on two sections of the document simultaneously in a split-screen view. The top part contains the text I’m writing, and the bottom contains my notes from a seminar on the topic. The file is stored as plain text, so I can add or edit HTML tags directly and even “publish” it on my local hard drive as a Web-browser-readable document. Plain text files are also the most durable archival format available for digital media; we can read text files stored three decades ago, and we’ll be able to read plain text files three decades hence.
The application pictured is one of the oldest computer programs still in regular use, a text editor called Emacs. While its history is long (I’m using Version 22.1.1), Emacs is certainly not outdated. With constant revisions by a large and vibrant open source community, it is still the standard text editor for many programmers. It also has a very small but ferociously devoted following among professional writers, some of whom sing its praises quite loudly.
Emacs doesn’t have a learning curve. It’s more like a cliff. If you install Emacs (it’s available for all modern operating systems) and simply fire it up, hoping to learn as you go, you will get absolutely nowhere. That’s because Emacs predates graphical user interfaces. While it uses modern windows and menus now, its command-line heritage is still visible everywhere. The keyboard “shortcuts” it uses also predate modern standards. For example, to quit Emacs, you use the sequence “ctrl-X ctrl-C”. That made perfect sense back in 1975. It would still make perfect sense, if that young whippersnapper Steve Jobs hadn’t come along and decreed “command-Q” as the standard shortcut to “quit.”
Jobs also spoiled everyone into believing we didn’t have to read any manuals. Emacs, in that respect, is implacably old-school. You can read the manual completely, then install and use Emacs without difficulty. Or you can prod around in the dark hoping to figure it out on your own, suffer hours of agonizing frustration, pore over error messages that seem deliberately obtuse, and finally, sheepishly, read the manual. One way or another, you will read the manual, or you will fail.
For those with the patience to learn it (I took about a week to become competent with it, and a couple of months to become moderately proficient), Emacs yields tremendous rewards. The keyboard shortcuts, while initially cryptic, eventually reveal their own logic. They’re also numerous. Though the mouse is often handy in Emacs, it is never really necessary; the entire application is controllable with just the keyboard. That’s a surprisingly useful feature when transcribing a fast-talking interviewee on a laptop. Because of its programming heritage, Emacs also offers a vast array of sophisticated text manipulation options, going far beyond the simple search/replace features of a standard word processor. There’s also an active community of Emacs hackers providing all manner of plug-in “macros” for customizing it, and the programming language underlying the application (Emacs Lisp) is simple enough that even novices can modify it themselves. Within days of installing Emacs, for example, I had added a line-wrapping feature and a word count algorithm.
Ironically, I never use Emacs for my programming. Every Mac comes with a suite of professional programming tools, including the Xcode development environment and text editor. Xcode has nearly all of Emacs’s advantages, but it adds a truly useful graphical interface. The only reason I don’t use Xcode for my regular work is that it’s too hard to customize, and there are a few missing features (such as word counting) that I simply can’t live without.
Smultron was also in the running as my editor of choice for awhile. With built-in word counting, elegant tabbed file organization, and one of the slickest, easiest-to-use interfaces of any application I’ve seen, it’s the Nisus Writer of text editors. Even a nontechnical writer could learn Smultron in a few minutes, and would quickly discover that it’s a far more agile composition tool than any business-oriented word processor. Among its many other endearing traits, Smultron is tiny, so it opens very, very fast. It can take half a minute for Word to lumber onto the screen from a cold start, even on a fast system. When I click the Smultron icon, I can start typing less than two seconds later. No more groping around the desk for a pen to take notes when some long-sought source suddenly calls back.
So why did I pick Emacs? I had all but settled on Smultron for my writing when I stumbled on an obscure little plug-in for Emacs, and it revolutionized the way I work. Look again at the screenshot above, and notice the orange and purple highlighted headlines. Those come from Org-mode, a note-taking/organizing/outlining system so astonishingly useful, it will be the topic of a separate post.