Connor, > The similarities between DM and Rio are actually startling; I wouldn't > be at all surprised if Rob Pike had previously seen Apollo...
Very likely. The Apollo founders all had strong academic and research backgrounds. Those communities were quite tight and interacted very regularly. > I'm not sure about your examples of modality within modelessness by > rebinding keys... But certainly I'm not opposed to the concept of > binding keys -- or more specifically, binding functions. My current > line of thought is similar to that suggested by Martin in the original > thread, whereby we have a command quasimode, so you can run arbitrary > commands just by holding Meta and typing the command. e.g., M-w would > save the file, M-/ would search, and so on. M-a would be kind of > pointless. > > What this would mean, though, is if you can create new commands (or > one might call them macros), you win a keybind automatically -- it's > just a case of being in the command buffer or otherwise holding Meta. > That is a very dangerous line to go down (see emacs), but with the > right steering I don't see why it would be inherently a bad idea to > add some kind of 'rc' file when the editor already depends upon > interpretation. You are right. Emacs chained key strokes are not an example of what has been termed modal behavior on this list. My point was that compile time key bindings conflates two separable design questions: 1) What editing operations will be available? 2) What sequence of key strokes will invoke any given operation? Answers to that second question are highly subjective, to whit posts to this list. The question can be left unresolved if users are free to implement their preference. But to get to that point one has to get past the attitude that any means of changing key bindings other than editing config.h would not be suckless. In describing the DM key binding mechanism and interpreter my goal was not to suggest it as a model to be copied. Rather I was trying to show that even with an incredibly rudimentary binding mechanism arbitrary decoding schemes become possible once persistent bindings can be redefined by any key stroke. Then schemes as diverse as emacs-like chained sequences and vi-like modes are all possible. > What's the etymology of the 'pad', by the way? Emacs must have existed > at that time, so why the use of 'pad' as opposed to 'buffer'? I do not know the source of the term 'pad'. My guess is that the allusion was to those things possible with a pad of paper: writing lines of text, drawing pictures, paging forward and back. On a related note: after more than two decades I have recently tracked down the DM's author - Jim Hamilton - so I may be able to get a definitive answer. /john