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 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 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.