Text editing, efficiency, and design.
The Craft of Text Editing — by Craig A. Finseth.
It’s interesting in that despite being written in 1991 most of what it covers regarding editor specific functionality and concerns is still valid. It’s essentially built around a model-view-controller pattern, long before the patterns book was published. There still hasn’t been much improvement on gap buffers or linked lists and such for modeling the data. User interface design is obviously important, if you expect to have any users. I like timeless shit like that.
A few parts such as chapter seven cover implementation and performance details which aren’t of particular concern today, but I think are still worth the read simply because it’s an interesting look into the sorts of tradeoffs one faces when performance matters (chapter seven itself even says as much, pointing out that for screen management you could just use the prevalent curses library). Thankfully we don’t generally use monochrome text-only terminals over a connection who’s speed is measured in baud anymore, but while people typing faster than the networked terminal could respond on slower connections is no longer a real concern, over time people have gotten lazy and despite multi gigahertz machines with megabit/sec connections we still deal with lag. The lag’s just in other areas now, but it’s still there, especially on the web. Especially when someone’s on dialup, or a cell phone, neither of which are exactly uncommon just as 300 baud connections wern’t uncommon in 1991. I’m thinking specifically of XML‘s rampant misuse for non-trivially-sized datasets here as one example where something like JSON or SQLite or Google’s newly released Protocol Buffers would be far more appropriate. Using scripting languages to implement entire applications (as in RoR, Django, etc…) would rank pretty high as well, but at least in those cases it’s the server’s CPU cycles they’re chewing away and not your own computer’s. Unless of course it’s also an AJAX site. Sigh.
Writing a new editor, of any sort, from scratch today would simply be retarded. You aren’t going to do anything new, editors have been done to death. It would accomplish nothing but a pointless reinvention of the wheel when all you needed to do was pick a well designed customizable editor, and learn to use it. Emacs, vi, LyX, Eclipse, TextMate, there’s shit loads of good editors already. But the fact that the book covers writing a text editor for obsolete equipment seems incidental to me. It’s more about properly designing software, using a text editor as a specific case example. In that regard it will remain valid for many years to come, especially in a world where test-driven development and “agile” development run rampant and naive programmers think “if it works, it’s done”. Not to say that TDD/Agile are bad ideas, I think TDD is awesome. But when they’re mis-used by the lazy, they’re fucking horrible.
 Design, not program. The book won’t teach you how to code in general, let alone anything usable, save for an appendix covering the minimum of C necessary to, with effort, understand the code examples. It was written for programmers, ergo it contains mostly concepts, not code.
 I know there’s going to be some ass chewing over this. Oh well.
 Especially handy when writing papers, articles, and such like. While the web has only recently begun to understand the value of separating content from presentation, it’s been around for document editing for eons. If you’re trying to do both at the same time, you’re wasting time. The trick is these two choice quotes from Bram Moolenaar:
“I want to get the work done, I don’t have time to look through the documentation to find some new command”. If you think like this, you will get stuck in the stone age of computing. Some people use Notepad for everything, and then wonder why other people get their work done in half the time…
Don’t overdo it. If you always try to find the perfect command for every little thing you do, your mind will have no time left to think about the work you were actually doing. Just pick out those actions that take more time than necessary, and train the commands until you don’t need to think about it when using them. Then you can concentrate on the text.
No comments yet.