Hey John, On 24 June 2011 19:13, John Yates <j...@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