Strange Strands

11 Sep 2006

Keyboard Chording

Since the Plan 9 editors, acme and wily, are very hot on mouse chording, I was thinking about how this could be extended to interfaces where chording is impossible, such as on a laptop. Though the biggest problem with editing is how to map the limited amount of keys to various functions (vi uses modes, emacs uses modifier keys), a secondary problem is that even solutions around this tend to be very limited. For example, vi has had to move into double commands such as gq, and emacs has had to use both Ctrl and Meta and double combinations of even those.

Enter keyboard chording. The basic idea is that you use a modal editing interface, and then two letter combinations for commands. But, and here's the novel bit, you a) require them to be two different letters, and b) allow them to be typed backwards. So for example, if "ij" were "paste clipboard", "ji" would do the same thing. This means that you can just hit at shapes on the keyboard and get it to do things. And because it's two character combinations, you get 26 choose 2, i.e. 325, command bindings to use.

As to how realistic this idea is, I'm not sure. In fact, I was thinking about it in the larger context of making editing as transparent as possible. I was thinking about how an editor could intuit what the user was wanting to do, such that flipping modes wouldn't be required. Of course, it's highly improbable that they'd be able to do so with, say, vi-like keybindings. Say I typed a word, and then was about to type the word "key", but then spotted a typo on the line above and wanted to move up to that line instead. I'd hit "k" and expect it to realise that I mean to go up... very implausible indeed. Even with some pretty fuzzy logic or some kind of software that learns, you have to doubt that it'd become that advanced.

So on the other hand, one of the nice things about the keyboard chording idea is that a lot of the pairs are probably going to be very uncommon in everyday input. You can think of it a bit like using the alphabetical keys as modifier keys. So, say, "hj" for back, "kl" for forwards, "jn" for down, and "km" for up... it could work. I suspect that there would be a bit of a learning curve, but with almost all advanced editors that's true anyway.

Beyond this, there's the issue of mapping the best keybindings to the best editing operations for the user. I think that this is something which should be studied more, across a variety of users. There are likely a great deal of shared operations, and a great deal of operations unique to particular users. Generally that's what builtin commands and macros try to cater to, but I doubt that much decent research has been done in the field.

On the other hand there are people like John Cowan, who calls himself an "ex troglodyte", which is to say that he uses the ancient line-mode editor called ex; basically vi without the visual aspect. The colon submodes of vi are what ex can do. This makes me wonder whether the most important factor of fast editing is to learn your editor really, really well; he's been using ex since 1985. But then again, I also wonder whether the simplicity of a line-mode editor has real benefits. I've been outlining a design for a line-mode editor, but I haven't really worked out the whole detail of editing complex documents yet: line-mode editing in general still seems very improbable to me.

Strange Strands, Keyboard Chording, by Sean B. Palmer
Archival URI: http://inamidst.com/strands/keychord

Feedback?

Your email address:
inamidst.com