Tools I Use to Write

I’m writing a novel, and I have a nerdy setup. I use Emacs, a text editor that was first released in 1976, making it almost as old as I am. This post is not a how-to. It is a description of and an apologia for my workflow. If there is interest, I will write a how-to.

“Why do you use that thing?”

A few weeks ago, my 15-year-old daughter saw me using Emacs to write on my laptop, and asked me, “Why do you use that thing?” The drawbacks of using Emacs are obvious: it has a steep learning curve; it is ugly, at least by default, and once you want to hand it off to someone else to read, you need to export it into a format that the editor or beta reader is familiar with. No one will question why you’re using Microsoft Word. The basics of using Word are easy enough for anyone to pick up, and everyone else uses it.

I made it over the most difficult part of Emacs’ learning curve sometime around 1992. When I was in college, most of the computers in the computer lab were UNIX terminals. These were X terminals, meaning that they had color graphical displays that could be used to view images and you could use a mouse with them, and all of the actual work was being performed on a big UNIX server somewhere else. The first text editor I found that let me use a mouse in this environment was Emacs.

I kept using it because it is customizable, because it can do everything I need it do, and because a large community of coders builds add-ons for it. Since I got past the initial learning curve, I’ve been able to work very quickly in Emacs, navigating quickly to different parts of a file or project using only the keyboard.

I’m a software developer, and I use it all day at work. Most of the developers I work with use big, complicated modern software, the developer equivalents of big, complex software like Microsoft Word and Adobe Photoshop. The ones who use an old UNIX text editor tend to use Vim, which, like Emacs, can be driven completely with the keyboard and has a steep learning curve. It has better keyboard shortcuts than Emacs, but is less extensible.

Markdown

Microsoft Word gives its users a huge amount of control over the formatting of their documents. (It does not, however, provide enough control: from a previous job, I’m familiar with Adobe InDesign, which provides more control, and much more consistent and predictable control, than Word.) All of that control comes with a price, however: the temptation to procrastinate by fiddling with the formatting to get it perfect, and, worse, the occasional, maddening paragraph or section of text that is formatted incorrectly.

Normally, what you edit in Emacs or another text editor is plain text: text that has no formatting at all. Markdown is a document format in wide use, implemented by any number of software tools. Markdown is a simple format that allows basic formatting to be embedded in plain text. Instead of selecting text and using your mouse to make it italic, you surround your text with asterisks or underscores, like this: _italic_. If you make a mistake, like forgetting the second _, it’s easy to see how you screwed up and how to fix it. So Markdown is a middle ground between all the formatting in the world, like what Microsoft Word allows, and no formatting at all. And Markdown has wide support from a number of different tools: if I decided I didn’t want to use Emacs anymore, I could easily switch to something else.

In Emacs, once you’ve installed Markdown support, the formatting that you apply in Markdown will be previewed inside Emacs.

Git

Git is version control software, normally used to allow multiple developers to collaborate on a software project and keep track of changes and versions. If you’ve ever named a file something like “Logo_FINAL.psd” or “Logo 2017-06-02 NO OWL.psd”, then you’ve got the idea. Instead of saving versions of an individual file, version control software allows you to save a version of an entire directory. Each change has a comment describing the change. It’s easy for you to see the list of versions and to go back to an earlier version.

I’m not very top-down with my writing. I tend to write a lot, and delete or clean up later. What using Git allows me to do is to kill my darlings without remorse, knowing that that piece of writing which I dearly love but which doesn’t actually work can easily be resurrected later. In practice, I can count on my hands the murdered darlings I have brought back from the grave, but knowing that I can always bring them back makes it much easier for me to kill them in the first place.

Git also makes it less stressful for me to make large changes, like changing the gender of a character, or rewriting something in the third person rather than the first person. What I can do, I can always undo.

Org-mode

Outside the novel itself, I keep a ton of notes. A lot of these notes are tasks. I leave myself notes to fill out a character, to resolve an inconsistency, to look through several chapters for changes that need to be made as a result of a change made earlier, to research something to make sure that a plot point is plausible.

Org-mode is software for Emacs to keep track of notes and tasks. It is big, unwieldy, complicated, and has a steep learning curve, like Emacs itself. Org-mode can be used for a lot of things, and what I use it for is to keep a summary of the novel, chapter by chapter, and a list of tasks to work on.

For each chapter, I have a summary, and the date in the novel in which the events occurred. If I want to check whether a character knows something at a point in the plot, or if I want to find out if an event occurred before a specific chapter, I can skim the chapter summaries, rather than looking through the entire book. I need to be disciplined, and update the summary for a chapter after I make important changes to that chapter.

Tasks that affect several chapters are listed at the beginning of the outline. Tasks that affect a single chapter are listed in the chapter or chapters that the task affects. I can quickly find tasks by searching for the string “TODO” in the outline. Theoretically, once I have no more tasks in the outline, the novel will be done.

Pandoc

When I have something that I want to send to an editor or a beta reader, I almost certainly can’t send her a folder of Markdown files. So I use Pandoc to export it to a Microsoft Word file. Pandoc can export to a number of different formats, like HTML, PDF, and Word.

Why I use that thing (reprise)

Using Git, I can keep track of the entire history of my novel, and easily take the whole novel or an individual chapter back to an earlier point in time. I can look through my history to find when I deleted a section or chapter, and easily bring it back.

You can use any file format with Git. It doesn’t need to be a plain-text format like Markdown. But a plain-text format makes each version take up less room on my laptop, and makes it possible to compare two different versions visually: in other words, using Markdown and Git, I can quickly see the difference between what my novel looks like now, and what it looked like a month ago. Viewing differences visually can be very useful if you want to find a passage that you deleted that you want to bring back. If I used Git to keep track of Microsoft Word files, I would need to open the file in Word and look for the passage I was hoping to find, which would not be much of an improvement over a folder of files with names like “Novel 2018-12-27.docx.”

Because I already know Emacs, and because Emacs is designed to be used without a mouse, I can quickly navigate and search through my novel without taking my hands off the keyboard.

I can work on my novel using a lot of the same tools that I use to edit software projects at work. I’m already a software developer, and I already know how to use these tools. To someone who is not a software developer, taking on the learning curves of Emacs and Git would be a large investment, and probably not worth it.

What I’d like to see eventually is a writing tool that has all of the advantages of my workflow—easy version control, open document formats, lightweight disk usage, a level of formatting control that is more suited to professional writing than to business documents—without its steep learning curve. Maybe someday I’ll build it myself.