frustrated Distraction-free writing

This is how I get started in my “writing flow” without getting caught in the details.

I used to get kind of overwhelmed when starting a new article. I might start writing a first draft, only to catch myself in the first paragraph by writing and rewriting a sentence that seemed awkward. This kind of self-editing during the “first draft” stage can stymie the writing process, breaking my writing flow and making it more difficult to finish what I was working on.

A colleague shared that when he wrote his first book, his editor recommended writing the first draft in a really tiny font size, so he couldn’t see what he was writing. And to turn off automatic spelling and grammar checking, so he wouldn’t be distracted by the word processing trying to highlight misspelled words or poor phrasing. All of this was to make it easier to focus on producing a first draft.

And a friend also shared that he likes to write his articles using Markdown. He explained that Markdown just makes it easier for him to focus on what he’s writing without getting distracted by what it looks like.

Over the last six months, I have explored other ways to make my “writing flow” more smooth. I found that what works best for me is to write my first draft using Markdown, like my friend, so I can focus on the content of what I’m writing and not think too much about how it will appear on the page. And to keep myself from self-editing during the writing process, I have adopted an old writing tool that, by its design, makes it really hard to go back and edit what I’ve already written.

A new use for an old editor

The ed editor on Linux and other Unix-like systems is a simple line-based editor. It’s arguably the oldest editor currently in use; Ken Thompson created a simple version of ed (based on another editor from that era, called QED) when he wrote the prototype Unix in 1969. ed has been updated since then, with new features including regular expression matching, but it’s still basically the same: a line-based editor that’s most suitable for typewriter-like terminals.

I start a new file using ed by typing the program name and giving it a file I want to work on:

$ ed article.md
article.md: No such file or directory

After that, it might seem that ed has stopped working, because it doesn’t print anything else except to say that the file doesn’t exist. But ed was developed in a time when terminals were TeleType terminals, which printed everything out on paper. TeleType printing was loud, so if a program could avoid printing unnecessary text, that made editing a little easier. Because of this, ed doesn’t actually print a prompt; you have to keep track of what you’re doing so you know when you’re in edit mode and when you’re not.

To start entering text, use the i command. This inserts text before the current line. GNU ed accepts the i command in an empty file, which basically means “start inserting text here.” On other systems, ed might instead prefer the a command to append text after the current line, which makes more sense in an empty file because the first line doesn’t exist yet, anyway.

i
# Learn Bash by writing a number guessing game

*Learning a new programming language can be a fun exercise.*

Whenever I try to learn a new language, whether it's a new shell scripting
language or a new programming language to write larger programs,
I focus on a few things: defining variables,
writing statements, and evaluating expressions.
Once I understand how to do those concepts, I can usually figure out
the rest on myown.

When I’m writing the first draft of an article, I find that Markdown makes it easy to focus on my writing without getting distracted by the specific formatting. I limit myself to simple formatting anyway, such as # to create a first-level heading, ## for second-level headings, * to add italics, and ** to format text as bold.

Self-editing is possible, but not as easy

If I make a mistake, such as a typo or a grammatical error, I can fix it pretty easily if it’s the line I’m working on. For example, I mis-typed “my own” as “myown” (no space). To fix this, I have to stop entering text by typing . on a line by itself, then I can use an editor command like s to change the text. As long as the edit I need to make is on the same line, the plain s command will operate on the last entered line:

the rest on myown.
.
s/myown/my own/
p
the rest on my own.

The p command prints out the current line, which shows the result of my edit.

It’s certainly possible to go back and edit previous text, but it’s not as easy as pressing the “Up” arrow a few times to move the cursor, then typing new text. ed operates one line at a time, so if I noticed my error after entering other lines of text, I’d have to use a different command like ? to search backwards to find the line of text I want to operate on, then make the edit. And with practice, this becomes natural. But it’s difficult enough that I just don’t bother - and that’s the point of a first draft!

This combination of writing first drafts with ed and Markdown helps keep me focused on my writing, without feeling the need to go back and edit something I’ve already written. I can save the editing for another time, after I’ve finished the first draft.

By the way, to keep editing, use the a command to append new lines after the current line. When you’re done editing, enter . on a line by itself to stop adding text, then use the w command to write the file to disk. The q command will let you exit back to the shell.

Distraction-free writing

This method works for me, but it’s only useful when I’m writing articles. Most publications that I work with prefer not to receive Markdown files, so I first convert my file to HTML, then copy and paste the contents from a web browser into another document, such as Google Docs or LibreOffice Writer. That’s where I make final edits, such as grammar and spelling, and rewriting any sections that need more work. But using this “distraction free” method lets me write the first draft very quickly, usually about an hour for an 800 to 1000 word article. And finishing the first draft is the key to technical writing.