Wred: a Proposal for an Inline Editing Language
Inspired by the discussion that followed this typecast just over a year ago (has it been that long already?), I’ve been working on developing a proposal for the editing language that I proposed in the comments. I call the concept “Wred,” which is a portmanteau of “writing” and “editing”. The basic premise of Wred is that it should be possible to use alphanumeric keystrokes to perform basic copyediting functions simultaneously with writing, resulting in a seamless “writediting” process that more closely reflects the iterative way our brains work during the process of creation, as opposed to the linear “write now, edit later” approach that we’ve always been taught and which, I contend, has been imposed by the mechanical limitations of the writing tools that we use.
Please note that Wred is envisioned as applying to on-the-fly copyediting (line editing) here, not developmental or substantive editing. The kind of thorough editing that leads to second and third (and fourth and…) drafts falls outside the realm of Wred.
I’ll be laying out my ideas for Wred here on Sotto Voce with the idea of making it an “open source” project that I hope will inspire discussion and ideas that could eventually lead to a working prototype and eventually a functional, expandable system. There’s a lot to cover: the theoretical basis for the Wred approach, finding the best methodologies for the various elements, figuring out how to kludge together a prototype, etc. But for now, here’s the case statement and hypothesis from the proposal. Please give it a read, and feel free to leave a comment or two with your thoughts and ideas (even if it’s just to say “That’s crazy talk!”).
The Case
Wred is the result of my attempt to answer a question: Why do many people find it “natural” to edit as they write, even though writers are told, and trained, to just “write first and edit later?” My argument is that the “write first, edit later” approach was originally dictated by the limitations of the dominant analog writing technology of the pre-computer era: the typewriter. This linear and sequential approach is the most proficient way to use the typewriter, because the tool as designed does not accommodate convenient simultaneous writing and editing. Over time, the proficient method was gradually transformed into the “right way to write” in the same way that many other practices and styles tend to become “rules” as they are passed down from generation to generation.
This issue is particularly important for professional copyeditors and copywriters who work on deadline and who often don’t have the luxury of multiple rounds of substantive edits before their work goes out the door and starts earning.
The problem is that, while modern text editors and word processors offer the potential for simultaneous writing and editing, we have continued to emphasize the pre-digital “write first, edit later” framework of the typewriter. Digital writing offers us the possibility of a nonlinear and nonsequential approach to writing that encompasses editing (consider, for example, collaborative real-time text editors, as well as text editors that track edits and allow the writing/revising process to be shown in playback as a fluid process that captures the working of the writer’s mind as part of, not prior to, the writing process).
However, the keystrokes that are required for typing and for editing are distinct and separate, which encourages practice that perpetuates a dichotomy between writing and editing. Writing uses the alphanumeric keys and punctuation, which are all “one keystroke = one glyph,” allowing continuous forward progress. Editing, on the other hand, requires multiple keystrokes in complex combinations (called “key bindings”), including non-alphanumeric operator keys such as CTRL, OPT, WIN/CMD, FN, and arrow keys, the use of which disrupts the forward progress of the writing.
This is, of course, largely due to the inheritance of the analog typewriter keyboard as the primary input device for text, on to which we have gradually grafted those editing-oriented keys around its physical — and conceptual — periphery.
With the rise of personal computing and particularly since the advent of the Web and mobile, we’ve seen the rise and proliferation of writing aids that use natural keystrokes to trigger actions (for example text expansion tools, macros, and shortcuts) and that encode design and layout features (for example HTML, Markdown, and assistive devices). Many of these aids are customizable by the user to allow them to fit more naturally into the writer’s workflow without being disruptive. In other words, these technologies use computer algorithms to allow the writer to combine traditionally linear and traditionally nonlinear functions in a single fluid and conceptually integrated process.
Hypothesis
It should be possible to create a writing aid that allows a writer to use a set of intuitive alphanumeric keystrokes to perform the most common copyediting functions in a way that is conceptually integrated into, and non-disruptive to, the writing process, thereby allowing the writer to combine writing and copyediting into a single iterative process that more accurately reflects the natural synthetic and simultaneous writing/editing process taking place in the head of the writer.
# # #
That’s the premise of Wred. In future posts, I’ll start laying out my thoughts on the components and architecture of Wred that I’ve developed so far. I’ve been doing a lot of reading in things like the methodologies of writing and editing, computer-language editing taxonomies, regular expressions, text expansion tools, macros, text editors that incorporate powerful editing technologies like vi and Emacs — just about anything that looks like it might have even some tangential bearing on the concept. It’s all a jumble, but I really think I’m on to something interesting here, and now that I’m going to have more time for such things, it’s about time I started devoting some brain power to it.
Wred on!
Categorised as: Wred
Comments are disabled on this post
It cannot have escaped your notice (can it?) that a major function and advantage of the separate writing/editing process is that it gives the writer a distinct time and space to reflect and evaluate the progress before rewriting certain parts. While Wred certainly would not prevent that, it might well encourage a writer to think that a work is finished well before it is the best that it could be.
Wred is a fascinating technical challenge, though.
No, it didn’t (I’m a fairly observant fellow). However, you’re talking about substantive editing, a very different beast from copyediting, which is what Wred is aimed at.
I did mention up front that Wred was designed for copyediting, but it probably should be emphasized throughout the whole post. Thanks for pointing that out; I will go back in and clarify.
As a mostly short-form copywriter, I tend to edit as I write. When you’re looking for 100 perfect words, fire-hosing the first draft is a wasteful exercise.
I believe that’s why I’ve become addicted to the Emacs editor keyboard shortcuts; I can dart around my copy as it’s written without really leaving the keyboard or using the spawn-of-Satan arrow keys.
Your progress on this should prove interesting.
I’ve come to realize that I’ve been pitching this to the wrong crowd. I should be pitching it to writers and editors like you who, along with programmers, understand the value of shortcuts and macros for boosting productivity.
The Emacs approach is very, very simpatico with what I’m aiming for. I think one way to describe what I have in mind for Wred is “shorthand regexp.”
I’m imagining something akin to a TextExpander shortcut that would enable you to invoke a long regular-expression string that performs a basic, predefined, on-the-fly editing function — say “delete previous sentence” — by typing, say, “ds.”
That’s a really basic example, of course, which could easily be performed by a combination of control and arrow keys (*crosses self*), But the premise of Wred is that if a writer can train himself to “edit forward” without having to physically stop the flow of writing to go backwards over text in order to change it, the writing process might become a more seamless, faster process. That’s very much like what you get with Emacs shortcuts, right?
For example, it took me practically five minutes to write that previous tiny paragraph, in order to get it just right. What if I could have kept on writing different iterations of it, getting clearer each time, while at the same time throwing short two- or three-letter Wred commands that would have deleted and overwritten stuff that I didn’t like, allowing me to overwrite as I went along? To allow me to just keep on typing. I would have been able to get into the creative flow and to stay in there, with faster and better results.
It would be like saying, “It was the grooviest, no, the gnarliest, no, the best of times, it was the crappiest, no, worst, of times, it was a time of really stupid idiots, no, the age of silliness, no, foolishness . . . ”
The Wred premise is about being able to make corrections (perhaps a better choice of word than the red-flag-to-a-bull “editing”) at a speed that’s closer to the speed that you actually think.
Actually, what you describe is a lot closer to the Vim text editor than Emacs.
You type an Emacs key combo, and something happens. Typically one thing. You can multiply actions, but you push buttons, it moves letters.
Vim lets you build actions one atop the other (“delete word for the next four words”) and lets you navigate without ever forcing your fingers from the home keys.
The price, unfortunately, is that it’s modal — you edit in command mode, and write in insert mode. (Here’s an interactive Vim tutorial.)
Not exactly what you were looking for, but it sounds a bit closer.
Thanks for the link to the tutorial. Vim is schweet! I looked at its big brother Vi when I was first playing around with this idea last year, but to be honest it intimidated the heck out of me.
Vim is perilously close to what I have in mind. Being able to fast-switch between the command and insert modes on the fly probably minimizes the whole “I’m writing, now I’m editing, now I’m writing again” phase shift. I’d love to watch a virtuoso play it, I bet it would be mesmerizing.
In true programmer fashion, though, the documentation is impenetrable (at least to this tech writer). What formats can Vim files be saved to? I’m assuming .txt is the default.
I will try to learn the heck out of Vim and see if Wred can complement it. Maybe that’s the sales pitch — “Hey, look! Vim for hipsters!”
PS — What if there was a “universal Vim” app that you could have running in the background that would allow you to use Vim/Vi key bindings in whatever app you happen to be typing in (composing an e-mail, working in a Word or Google doc, etc.) without requiring the modal switch? Say, by prefacing the command with a punctuation mark (a la TextExpander, which uses prefix commas in its default set), I wonder if that wouldn’t solve 95% of the problem that Wred is trying to address…
It could be called Vigor.
I use the Firefox browser (and Gmail) and Firemacs plug-in, so when I’m not writing in Emacs, I can use many of the Emacs key bindings.
When I switched to Chrome (for a while), it didn’t support a similar plugin, so I ran an “edit server” in the background. This allowed me to click on a text box and watch it turn into an Emacs window.
I don’t know if VIM (or GVim, the GUI alternative) offer something similar.
Gvim (or Vim) is — on paper — the kind of text editor I would love. Small, fast, infinitely power… Yet I never could get used to the modal bit.
There is also a tarted-up version of Gvim that follows most of the “normal” editing conventions. It’s called Cream. It has an expert mode that allows you to use it like a normal person, yet invoke the admittedly cryptic Vim commands when you wanted.
[…] out that the terrific text editor http://www.vim.org does an awful lot of what I have in mind for Wred, but best of all, Vim has been around for almost a quarter-century and has a dedicated and […]