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

Hey John,

On 24 June 2011 19:13, John Yates <john_AT_yates-sheets.org> wrote:
> While following the st and editor threads I felt prompted to put down
> these reminiscences.  My hope is that they will stimulate the
> discussion.

Thanks a lot, this was fascinating. I'd not heard of Apollo before,
but it seems to bear a similarity to the ideas I've had in my head for
the editor. A natural side-effect of the model I've been designing
means that it would be trivial to include "transcript pads" of pipes
and so on. My design shares the idea (also shared in a less strict
sense (?) by emacs) that everything is a "text canvas", editable or
not, and backed by a file or not...

The similarities between DM and Rio are actually startling; I wouldn't
be at all surprised if Rob Pike had previously seen Apollo... They
even share the 'hold' mode (activated in Rio (or 9term) with ESC).

Although we aren't attempting to create an entire operating system
interface, the Apollo-esque route is definitely the sort of line down
which we are going, simply by virtue of being a descendant of sam --
you can edit arbitrary text, and run shell commands, so ~

> Once a script existed each user
> was free to invoke it via whatever binding (s)he might choose.  From
> this perspective the suckless proclivity for freezing key bindings at
> compile time is overly constraining.

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.

> DM input pads finessed this problem.  No Apollo readline-like
> capability ever existed. Apollo commands read directly from stdin and
> consumed the result without further processing.  Users were forever
> free to redefine their key bindings to suit their whims.  Editing
> one's command input always honored one's idiosyncratic key bindings.

I consider the shell just a special case of text editing -- your
command history is immutable, yes, but what you haven't sent to be
executed yet is perfectly editable with your standard text editor... I
plan to support full-duplex streams (in ttys and sockets alike) such
that you can just treat text as text, and indeed perform full regexp
commands on those buffers, so you can actually command dozens of
command windows, each running their own shells. I don't have to build
this in, it just happens. It sounds like Apollo's 'pad' abstraction
was a similar idea.

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'?

> With access to this script it should be obvious how one proceeded:
> execute "ls -1 <pattern>" (no need for redirection), hit whatever key
> invoked copy-last-command-output-to-input-pad, use a regular
> expression to turn the listing into a set of rename commands, release
> hold.

This is a nice idea -- I'm all for reducing the set of primitives...
Making stuff like this as quick as possible would be great, such as
allowing the user to quickly alter the text and then hit M-!, running
all the commands. This is similar to Acme (inspired by Oberon), only
you don't have to prod everything with your cursor. (But you can.)

I'd quite like to create a sane system for separating streams so that
we don't have to search back for a shell prompt, which is ambiguous
(but also how they did it in Rio, surprise surprise). If you (or Kurt)
have any ideas about this I'd love to hear them.

In a similar vein I've been thinking that command buffers ought to be
'magic' to some degree: all windows should only hold one view of one
buffer, but command buffers ought to hold pointers into ranges within
other buffers, such as a regexp match: unlike sam, you can actually
edit the output of an 'x' command match and it affects the appropriate
buffer... I don't know precisely how this ought to work. But a natural
extension of this is that the output of each command can be in its own
separate buffer, exactly the same as matches are, and the command view
just collects these disparate buffers in one place for your perusal
and editing.

Needs more thought? :)

Thanks,
cls
Received on Sat Jun 25 2011 - 01:56:54 CEST