Why I Don't Use a Word Processor (3)

In the most recent post in this series, I described the programs that I use in place of a word processor. This time, as promised, I will begin to discuss exactly why I find these programs to be far more useful than a dedicated word processor.

There are two fundamental reasons for preferring programs other than word processors (as well as other, less basic reasons such as the general instability and frustrating clunkiness of word processors). These are: (i) clear separation between the processes of defining content and defining form; (ii) precise control over every part of every printed page. In this post I will look at the first of these.

Defining Content and Defining Form

In a modern word processor, there is no clear separation between the action of typing content and the action of determining how it will look on the page: as one types the story, one is continually aware of how the final page will look. This is not useful for at least two reasons: firstly, the look of the page continually distracts from the task at hand, which is the creation of the story; secondly, one loses a lot of context because the word processor displays a relatively small amount of text at a time.

To this second point, consider a manuscript that is being created for submission to an agent or a publisher. Professional submissions are expected to conform to typical industry expectations -- basically, the page is expected to look more or less as if it had come from a typewriter: double-spaced in a monospaced font, in accordance with certain expectations regarding layout and conventions to indicate changes of font. So as one types, one is faced with something that looks like this (the text is taken from the beginning of Reflexive Action):

Now, this is great for printing out on paper, and marking up changes. But it's pretty poor for typing a story:

1. There's just not enough context visible (what did character X say fifteen lines ago? What colour did I say that wall was on the last page?). 
2. Space is wasted, and the flow is interrupted, by the headline on each page.
3. The conventions for changes in typeface (underline for italic, double underline for bold) mean that when the time comes to generate the final PDF for printing, every such change has to be converted to actual italic and boldface.
4. Other conventions render the change from typescript format to ready-for-publication format unnecessarily difficult (for example, the first paragraph in each chapter in printed books is by convention not indented, whereas in a typescript it is indented).

This is certainly not to say that one can't use a word processor, but it's very difficult to make a professional-looking product without jumping through some hoops -- and writing is difficult enough already, without burdening oneself unnecessarily.

Here is the same text, rendered in the VEDIT PLUSprogram that I use:

Roughly twice as much text is immediately visible as one is working. Further, any good programming editor allows multiple independent split screens to be visible simultaneously, so that one can keep important text in full view on the screen. There are other advantages to such editors (such as in-context listing of all occurrences of a particular string, or lightning-fast search and replacement), but I find it hard to overestimate the usefulness of having so much text on the screen, especially if one maintains several independent panes open on different portions of the text, as I find myself doing.

Another advantage to using an editor is that the text is stored in a universal file format -- there is no chance of being unable to work on a book fifteen years later because one's word processing format is no longer fully supported by the current generation of products.

Really, though, all these are relatively minor in comparison to the huge advantage of eschewing word processors (although cumulatively I think that they add up to a pretty strong argument in favour of the approach I use) -- and that comes into play when it's time to create publication-quality output. Which brings us (next time) to the issue of defining form.