Re: [dev] Re: The Apollo Display Manager [very long]

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
Received on Mon Jun 27 2011 - 00:59:49 CEST