Aucbvax.4233
fa.editor-p
utzoo!decvax!ucbvax!editor-people
Mon Oct 5 15:30:37 1981
Forwarded note #2
>From sklower Mon Oct 5 15:30:18 1981
Mail-from: ARPANET site MIT-MULTICS rcvd at 2-Oct-81 0703-PDT
Date: 2 October 1981 10:03 edt
From: Greenberg.Symbolics at MIT-Multics
Subject: Re: emacs and unix
To: Earl A. Killian <EAK MIT-MC AT>
cc: editor-people at SU-SCORE
In-Reply-To: Message of 2 October 1981 02:29 edt from ARPANET site MIT-MC rcvd
Yup, Multics Mode is as hairy as hell. The littlest part of it
is binding CR to a key that sends the line to the command processor.
What EAK didnt mention is that INPUT requested by programs
invoked in this mode must fetch input from the buffer, too. What's
more, output must appear as it is produced! In fact, before there was
Multics mode, one simPly called commands from Emacs, routed all ooutput
to a file, and then read in/displayed the file. All the difficulty,
which takes full advantage of the generality of Multics, is in
creating I/O streams that are really attached to Emacs buffers and
operate in real time as input and output requests are made.
Unix with pipes can do that pretty easily, but if I think
of what it would take on ITS to do that, I cringe. Complex subsystems
(like the Lisp subsystem on Multics) that are call-back-into-able from
another subsystem to which they have calledout are a luxury.
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
