Another one of these days that makes me appreciate Unix and having read The Pragmatic Programmer. My student was struggling with a log file containing, among others, a hex dump of some weird data needed to talk to a Bluetooth chip that he needed to convert to a C array initializer. He was typing along rhythmically, sighing, having accepted that he would have to press right, right, right, right, comma, right, right… and so on, until somewhere around the evening he would be finished. When I showed him the search/replace function he was jumping with joy: All he needed to do was replace every space with a comma-space combination at certain places in the file. Much easier. Had he been using VIM, he could have recorded a quick macro and his editing would have been over in a minute.
Which begs the question: Why do people not even use a functionaliy as simple as search/replace? He’s a bright guy who works with the Linux shell all day, writes C and C#, but textual editing above cut/paste still eludes him. Well, at least he doesn’t use the mouse to pop up a menu to select the Paste command from. But up until now, he never saw the necessity for looking at his editor a little closer, find out what else it can do. Just like lots of programmers I’ve met, including myself — before I had read The Pragmatic Programmer, and its fervent advocating of learning to use one editor really, really well, no matter which one.
Just having turned my eyes towards Linux, naturally I selected VIM as my tool of choice. Hey, stop hitting me, I do use Emacs when editing Lisp code! But my hands tend to find VIM more comfortable: No more RSI. Nice.
Before learning VIM, I was a happy Gedit user. But still, being a programmer I did work a lot with textual data, but never used anything more advanced than cut/paste. At first, learning how to use VIM was a pain. The learning curve looks more like a vertical mountain slope, and there are way too many bizarre commands you think you’ll never need. After all, I can just move upwards a few lines, press V, go down to the end of the block, and press >> to indent it, right? Why learn a special three-character-sequence for that?
Because it will make you faster. Once those strange commands have found their way into your muscle memory, suddenly your friends and collegues will get all excited when looking over your shoulder while you do some editing. What you do to the source code becomes magic to them, and you become a wizard wielding a powerful tool. Using a system that doesn’t have your editor on it becomes a pain. Which is another reason for my advocating VIM: It’s everywhere! Unless you’re a Windows user, but even then you can install a port.
Back in 1992, I used my trusty old Commodore 64 to do my homework. The Pagefox module (German link) had three modules: A pixel based graphics editor, a layout editor, and — a text editor. You’d write some text, add a few formatting codes1, then you would paint a few boxes in the layout editor, placing bitmaps somewhere on a virtual sheet of paper, and start the formatter, generating a pixel based representation of the text entered before. Using it was pure bliss: While working on the text, you could concentrate on the content, without thinking about how the text would flow around an image placed somewhere on the page. That came later, at layouting time. In contrast, when you write a document in one of the modern WYSIWYG word processors, you are constantly reminded of the “exact” location on the page where a word will have to move into the next line, where a page break will occur and so on. Distracting, isn’t it? If you write lots of textual documents, try an experiment: Write your texts in a plain text editor, then copy and paste into your word processor and add whatever formatting you want. Do you find it easier to concentrate on the actual content when writing in this fashion? What if you had a more powerful editor that could make your editing even faster and more pleasant?
Of course there are lots of systems nowadays that use the same method of formatting textual data2. The simplest of them seems to be Markdown, a very basic but powerful system to turn a plain text document into a formatted one. Another system worth looking at is LaTeX. Extremely powerful and the de-facto standard in scientific publishing, but not as simple as Markdown. This is perfect for longer, complex documents, like PhD theses. And then, nearly forgotten, there is the *roff family of text processors:
groff and all the others. Quirky little programs that take what can only be described as an obscure programming language as input and produce beautiful papers and reports as output. They were part of the Unix text processing system, and parts of this system are still in use in every Linux and BSD system: Whenever you call up a
man page, there is a
groff instance running in the background turning the source code of your desired
man page into a nice document to view on screen. If you want, you can turn every single
man page into a beautifully formatted PostScript document that you can send to your printer or convert to PDF.
What you are currently reading was written in Markdown, using VIM on the text mode console of my Linux box. I like to use text mode to edit longer texts, because there is no browser, email notifications or whatever distracting me from writing. Just VIM and me. Oh, and Git. Wait, what? I thought that was for managing source code? Yes, and no. Not only. As soon as you are dealing with a plain text file, you can use all the goodies programmers use at work: Source code management tools like Git become a safety net for your document. Write a few sentences, then
git commit to save the current state of your text. Unlimited undo capabilities! If you’re not sure about how to approach a chapter, create a branch and go wild. If you like the outcome, keep the branch, otherwise just checkout the
master branch again. Merging and even cherry picking works too — try that with a WYSIWYG text processor!
And all the other power tools are there, too. Every Un*x box comes with
awk, two powerful little programs that let you run automated text processing scripts for everything a simple VIM macro is not enough for. Or write a Perl script to do the heavy lifting for you. Compare different revisions of your document with a basic file differ. The possibilities are endless.
As they were decades ago. We just went on to “simpler” tools, focusing on the looks of our documents while we are writing them, modifying their looks by clicking around with a mouse. Much simpler, sure, and easier to learn. But sometimes you want a power tool, and editing plain text documents can give you just that. I can’t even remember how many times OpenOffice crashed while I was working on my thesis. MS Word kept changing image placements, layout and formatting data. Only when I switched to plain text and LaTeX could I finally concentrate on getting the job done.
Oh, and by the way, nearly everything in a Un*x system is a plain text file. Configuration (always place
/etc in a Git repo!), scripts, directory listings, log files… once you have learnt to use
perl and a good plain text editor, you have an immensely powerful toolset. So go ahead and learn. You’ll never look back.