It’s funny that this came up on LessWrong around this time, as I’ve just recently been thinking about how to get vim-like behavior out of arbitrary text boxes. Except I also have the additional problem that I’m somewhat unsatisfied with vim. I’ve been trying to put together my own editor with an “API first” mentality, so that I might be able to, I don’t know, eventually produce some kind of GTK widget that acts like my editor by default. Or something. And then maybe it’ll be easy to make a variant of, say, Thunderbird, in which the email-editing text box is one of those instead of a normal text box.
(If you’re curious, I have two complaints about vim. (1) It’s a little bloated, what with being able to open a terminal inside of the editor and using a presumably baked-in variant of sed to do find-and-replace rather than making you go through a generic “run such-and-such program on such-and-such text selection” command if you want the fancy sed stuff. And (2) its commands are slightly irregular, like how d/foo deletes everything up to what the cursor would land on if you just typed /foo but how dfi deletes everything up to and including what the cursor would land on if you just typed fi.)
Vim is far from optimal, but it’s very customizable, which makes it easy to paper over the more obvious cracks.
For alternative ideas, the Canon Cat had a pretty well-designed interface for text editing, which Jef Raskin described in The Humane Interface, which has influenced my thinking about UI design. It’s still not as fast as Vim, but much easier to learn. The 80% solution for the 20% effort maybe. If you want to try it out, it’s old enough that you can emulate it in your browser, although I had to download MAME to get all the keybindings working.
It’s funny that this came up on LessWrong around this time, as I’ve just recently been thinking about how to get vim-like behavior out of arbitrary text boxes. Except I also have the additional problem that I’m somewhat unsatisfied with vim. I’ve been trying to put together my own editor with an “API first” mentality, so that I might be able to, I don’t know, eventually produce some kind of GTK widget that acts like my editor by default. Or something. And then maybe it’ll be easy to make a variant of, say, Thunderbird, in which the email-editing text box is one of those instead of a normal text box.
(If you’re curious, I have two complaints about vim. (1) It’s a little bloated, what with being able to open a terminal inside of the editor and using a presumably baked-in variant of sed to do find-and-replace rather than making you go through a generic “run such-and-such program on such-and-such text selection” command if you want the fancy sed stuff. And (2) its commands are slightly irregular, like how d/foo deletes everything up to what the cursor would land on if you just typed /foo but how dfi deletes everything up to and including what the cursor would land on if you just typed fi.)
Vim is far from optimal, but it’s very customizable, which makes it easy to paper over the more obvious cracks.
For alternative ideas, the Canon Cat had a pretty well-designed interface for text editing, which Jef Raskin described in The Humane Interface, which has influenced my thinking about UI design. It’s still not as fast as Vim, but much easier to learn. The 80% solution for the 20% effort maybe. If you want to try it out, it’s old enough that you can emulate it in your browser, although I had to download MAME to get all the keybindings working.