When you work in the UNIX / CLI-environment a simple fact of your work environment is that you simply must have a high-powered text editor to edit configuration files, write code, or write email in a non-GUI mail tool. You have your choice of consumer-targeted editors (=pico=), but the two that battle for the power user demographic are vi and emacs.
I’m conversant in both and have even written an encomium to the power of emacs on this very site. But I should like to dwell on an interesting aspect of the vi/emacs approaches to doing things.
I had occasion to reflect on vi/emacs as writing tools when I was giving my exceedingly patient girlfriend a bit of a demo of how to use vi ( being knee-deep in drupal, it is something she’s considering needing to know more about ).
Teaching the Command Mode / Insert Mode Bifurcation
My first topic was the difference in modalities in vim. This was something that I thought would be particularly hard to communicate. Given a world where most grow up with the WYSIWYG experience of textual editing ( MS Word, chiefly ) people are used to combining three activities which need not necessarily be defined within the same context. Here’s how I believe the Unix modality considers the activity of producing a “fine document”, as opposed to the default “type, edit, and print it from Word” assumption.
- Writing:
- Editing
- Layout
Writing
Writing is: typing in a serial fashion, verging on ‘stream of consciousness’. When the “flow” ends, change modes. Vi notes this “shift” in gear by a stroke of the escape key, that is changing modes from insert to command. Emacs does not observe this modality change.
Editing
Editing is fixing typographical errors, re-arranging text, reading, cutting, pasting, doing formatting changes, and iterative edits. By in large one is not “writing” here - one is clarifying and largely reading. Where one sees the opportunity for an edit it is, generally, small ( replace ‘r’ with ‘R’ )
Layout
Layout in the Unix mentality is done by LaTeX. That is, after writing text, one edits the content and wraps the content in LaTeX markup. Having done this, one processes the content through a LaTeX editor and then can view the typeset materials.
Nota Bene: Neither vi nor emacs are in the business of layout. When writing in a text editor you are free to think about writing or editing but do not have to worry about, are explicitly prevented from, thinking about layout. It’s writer’s bliss to focus on expression, not bold.
Non-Unix Workflow: Word
Now let’s proceed from Word. Word starts with conflated editing, writing, and layout. My girlfriend, a professional writer, immediately needed no convincing on the wisdom of ditching the layout to focus on the content. Her process is very ‘layout comes later’ intensive. Our conversation then turned to the difference in should editing and writing be conjoined (emacs) or should they have a modal difference. This is a philosophical difference between the two ne’er the twain shall meet.
Most people coming from Word are conditioned to anticipating the instantaneous response that emacs gives. While the commands might be a bit different (Control-b for “move cursor left”), and the mouse absent, the idea is not a departure from the generally conditioned experience.
But the modality shift between the command and insert modes of vi - that presented a bit of a conceptual hurdle. Not to be misunderstood, my lady fair most certainly understood the value of separating the activities, and certainly understood that ‘i’ or ‘a’ could be used to enter insert mode and escape was used to exit it, but she had the concern that her work-flow would be interrupted.
She also suggested that the multiplier+command core feature of vi - something which I use to great effect - seemed to require an amount of ‘pre-thought’ before the editing.
She’s absolutely right. You see, vi was written by Bill Joy on a slow connection. While he waited for his 300 baud command to be received and worked upon he could look at the screen and say: “Hm, I need to go three sentences ahead and delete 3 words, and then go to the end of the paragraph and insert a period”. This translates to
- 3)
- 3dw
- }
- A.
MIT had much speedier connections and thus Emacs was written from the instantaneous response perspective.
In some ways I think vi is like Kendo or Latin. You have to churn the mental gears before you act, but when you do act, you act decisively, cleanly, with a minimal amount of effort; but great power, and great conciseness.
Emacs is more like an interpretive dance: I go this way, I go that way, I change this, no I change that, etc.
I’m not sure if I have convinced her one way or the other.
Which is better
In many ways I feel like vi is the winner for writing text and email. It’s fast, light, and encourages more prethought, more editing, and more post-thought. A great many email writers (and bloggers…) would benefit from that. Somehow the mode change seems to engender a more reflective attitude to writing, and this is a very fine thing indeed.
But what about code?
Hm, it’s tough. I want to say emacs is because code is not like writing and then editing, it’s a much more “oh crap i forgot a ;” or “where’s the closing brace”. There’s less forethought, and more experimentation. If what I say above be true, then emacs should win hands down.
…but….
The keystrokes from emacs and holding their configuration wears on my fingers: Stroke after stroke of the Control+letter commands makes my carpals act up. And, on the other hand, perhaps a bit more thinking before typing the code is warranted: the moment to reflect on whether a pattern might be appropriate, a second to consider where iteration is called for and building the abstract iterator before passing the commands.
So for code, I think I’ll have to call it a draw.
But I especially love ‘vi’ for editing. The enfolding blackness of the command line and the hollow green of the text says “low fi” which is exactly why I find it so easy to do creative writing in vi versus any other editor.
That said, most of the time on my Mac I tend to use Textmate which is, essentially, a much better emacs minus the emacs religion + some of the power of a flexible IDE.
