Today's been an interesting day already, with deltab providing the Television Tropes, Idioms, and Devices as a source of entertainment, and the source of a few patterns. One such pattern was up a meta-layer in thinking about the Tropes/Idioms wiki itself: its titles are often memeworthy, it recourses to a particular hyperbole phrase "used in every episode of..." frequently (every page!), and so on.
I had one of my brief but pithy conversations with DanC on #rdfig where I managed to get out an observation on abstract/introductory repetition which I can now cite when I want to bring it up. And there's the results of a musing on Swhack given the premise "rich nut emails you and gives you a practically unlimited budget to come up with your own OS".
But what I'm focussed on generally at the moment is the Seven habits of effective text editing article. Basically, it's thinly-veiled VIM propoganda, but it neatly exposes the problem that it's difficult to talk about editing without resorting to explaining it with a particular instance of an editor.
So I'd been thinking that it would be nice to write an article with the following premise: if you're a good enough programmer, then you ought to be able to systematically analyse the kinds of editing tasks that you're most likely to perform, and then build an editor around your own observations.
I know that listening to someone talk about User Interface is very tedious...
"I'm a bit embarassed, as everyone has pet ideas about how the UI is frustrating, and listening to them can be tedious, I know! Perhaps this is why I haven't written this down before."
—TimBL, Editing User Interface
But such an article could assuge that problem by concentrating on design patterns that can be reused (which is where the wiki names thing from earlier comes in). For example, I recently decided that if I were to work on an editor for myself, I'd like to abstract all the events so that I could have seperate GUI (wxPython) and text-mode (ncurses) implementations, ensuring that I wouldn't have to adapt depending on whether I'm using a terminal or a GUI OS.
The main thing that one has to decide in such circumstances is whether the effort put into such a task is going to be more than offset by the benefits or not. Morbus has talked about this:
I'll drop everything I'm behind deadline on and spend 20 hours automating a task that takes five manual minutes; I know I'll eventually recoup the benefits months down the road, after I've long forgotten the automation exists ("you only notice electricity when it's missing"). I've automated iTunes album listings, video file annotations with AppleScript and Perl, have tried numerous todo and schedule outlines, and generally enjoy having my computer be far more "robot" than those of 90% of the populace
—Morbus Iff, Failing Miserably, If Not Inventively
Morbus came up with a rather shocking (or simply catalystic, as he put it) piece of rhetoric the other day about productivity that gave both deltab and I food for thought for some time, but that'd probably best be left to another rant. Funny how it partially resulted in my finding out that the song Lone Green Valley is a derivative of Pretty Polly. According to Google, no one seems to have noticed that before.