From MOON at MIT-MC Tue Dec 29 00:00:00 1981 From: MOON at MIT-MC (MOON at MIT-MC) Date: 29 Dec 1981 00:00 Subject: STY question Message-ID: :doc .call styget It's documented to "probably not work very well". I don't know whether or not that is true. From MACRAK at MIT-MC Mon Dec 28 00:00:00 1981 From: MACRAK at MIT-MC (MACRAK at MIT-MC) Date: 28 Dec 1981 00:00 Subject: No subject Message-ID: How do you check if the far end (user) of a STY is waiting for input? From JPG at MIT-MC Mon Dec 28 00:00:00 1981 From: JPG at MIT-MC (JPG at MIT-MC) Date: 28 Dec 1981 00:00 Subject: No subject Message-ID: My apologies for my recent BUG-ITS notes. I forgot I was logged in as JEFFG when I typed X^K, and the error message was not at all helpful in this regard. From JEFFG at MIT-MC Mon Dec 28 00:00:00 1981 From: JEFFG at MIT-MC (JEFFG at MIT-MC) Date: 28 Dec 1981 00:00 Subject: continuation: Message-ID: From JEFFG at MIT-MC Mon Dec 28 00:00:00 1981 From: JEFFG at MIT-MC (JEFFG at MIT-MC) Date: 28 Dec 1981 00:00 Subject: No subject Message-ID: Why does :XFILE JPG;JPG ^Q_X work, but not X^K ? The latter has always done the trick in the past. From GSB at MIT-ML Wed Dec 16 00:00:00 1981 From: GSB at MIT-ML (GSB at MIT-ML) Date: 16 Dec 1981 00:00 Subject: No subject Message-ID: CADR, CADDR, and CADDDR should be synonyms for the SECOND, THIRD, and FOURTH devices. Perhaps also there should be an NTH device which is the "last" one in the sequence, for not-quite-tape archival. From EAKatMIT-MC Tue Dec 15 00:00:00 1981 From: EAKatMIT-MC (Earl A. Killian) Date: 15 December 1981, 00:00 Subject: No subject Message-ID: Date: 12/12/81 18:21:15 From: DEVON at MIT-ML Of course this penalizes a (hypothetical?) user with lines of 128 or longer in favor of a user with slow connection, but does anyone really want 128. characters on a line? Yes. Date: 12/15/81 03:45:44 From: DEVON What should happen if a multi-character sequence like %TVMV0 gets an argument byte valued 214? It moves to that line/column of course. Is this to be taken as a %TDORS which has already flushed the real argument bytes further up the pipeline? No. Or must every buffer know about such sequences and delay the action of a %TDORS until this situation won't arise, Something like that. or do argument bytes 214 and 215 get quoted by %TDQOT? No, that's not at all the function of %TDQOT. From DEVON at MIT-MC Tue Dec 15 00:00:00 1981 From: DEVON at MIT-MC (DEVON at MIT-MC) Date: 15 Dec 1981 00:00 Subject: SUPDUP Message-ID: What should happen if a multi-character sequence like %TVMV0 gets an argument byte valued 214? Is this to be taken as a %TDORS which has already flushed the real argument bytes further up the pipeline? Or must every buffer know about such sequences and delay the action of a %TDORS until this situation won't arise, or do argument bytes 214 and 215 get quoted by %TDQOT? From DEVON at MIT-ML Sat Dec 12 00:00:00 1981 From: DEVON at MIT-ML (DEVON at MIT-ML) Date: 12 Dec 1981 00:00 Subject: No subject Message-ID: Another Output-Reset related gripe: when output characters reach the level where flow control happens, they are no longer flushable. This means that during a long listing I can type ^S (knowing that DDT will eventually shut up ten-twenty lines later) and before output stops I can use the intelligent terminal protocol to stop and start output several times, bacause response speed to flow control is an order of magnitude better than the response to ^S. If multi-character %td sequences were forbidden argument bytes >177 then %tdors would behave more like a genuine out-of-band signal, and maybe that would make it permissible to flush a buffer without knowing about multi-character sequences. Of course this penalizes a (hypothetical?) user with lines of 128 or longer in favor of a user with slow connection, but does anyone really want 128. characters on a line? From MOON at MIT-MC Fri Dec 11 00:00:00 1981 From: MOON at MIT-MC (MOON at MIT-MC) Date: 11 Dec 1981 00:00 Subject: When does ITS send %TDMOV ? Message-ID: When %TOMVU isn't set, thus the terminal needs to know where it's coming from as well as where it's going to. This would be the case on printing terminals. User-mode programs such as Emacs and Macsyma may send it in other circurmstances as well. From DEVON at MIT-MC Fri Dec 11 00:00:00 1981 From: DEVON at MIT-MC (DEVON at MIT-MC) Date: 11 Dec 1981 00:00 Subject: No subject Message-ID: when does ITS use %tdmov instead of %tdmv0? I never recieved (or bothered to implement) %tdmov on my terminal until just now, while testing a gross kludge that changes my tctyp to printing momentarily, upon changing it back I got all %tdmov's for a while. I'd like to know how to induce ITS to revert to the shorter %tdmv0. From CStacyatMIT-AI Sun Dec 6 00:00:00 1981 From: CStacyatMIT-AI (Christopher C. Stacy) Date: 6 December 1981, 00:00 Subject: No subject Message-ID: ALAN at MIT-MC 12/05/81 16:22:32 Am I to understand that this means that version 1388 of DDT has ... Pissed off,Alan No. From ALAN at MIT-MC Sat Dec 5 00:00:00 1981 From: ALAN at MIT-MC (ALAN at MIT-MC) Date: 05 Dec 1981 00:00 Subject: No subject Message-ID: I reinstalled the old version of ddt From ALAN at MIT-MC Sat Dec 5 00:00:00 1981 From: ALAN at MIT-MC (ALAN at MIT-MC) Date: 05 Dec 1981 00:00 Subject: No subject Message-ID: I reassembled and installed DDT 1388 on MC so that it will use the correct new hsname scheme. Chris Please do not make modifications to existing installed code without upping the version number. Some people's ready messages are assembled code and expect certain entrypoints within DDT. The loader checks to see if the version has changed, and if so does not load the ready message. Am I to understand that this means that version 1388 of DDT has a different mapping from symbols to locations depending on what MACHINE it is running on? That is TOTALLY unacceptable and completely brain-damaged. What good is a goddamned VERSION NUMBER anyway if you don't CHANGE it when you change the VERSION!!! Pissed off, Alan From DCP at MIT-MC Sat Dec 5 00:00:00 1981 From: DCP at MIT-MC (DCP at MIT-MC) Date: 05 Dec 1981 00:00 Subject: No subject Message-ID: I reassembled and installed DDT 1388 on MC so that it will use the correct new hsname scheme. Chris Please do not make modifications to existing installed code without upping the version number. Some people's ready messages are assembled code and expect certain entrypoints within DDT. The loader checks to see if the version has changed, and if so does not load the ready message. From CHRIS at MIT-AI Sat Dec 5 00:00:00 1981 From: CHRIS at MIT-AI (CHRIS at MIT-AI) Date: 05 Dec 1981 00:00 Subject: No subject Message-ID: I reassembled and installed DDT 1388 on MC so that it will use the correct new hsname scheme. Chris From MOON at MIT-MC Wed Dec 2 00:00:00 1981 From: MOON at MIT-MC (MOON at MIT-MC) Date: 02 Dec 1981 00:00 Subject: System console Message-ID: I don't think it's easy to make different consoles have different size buffers. What information is it that you want to see? From ELLEN at MIT-MC Tue Dec 1 00:00:00 1981 From: ELLEN at MIT-MC (ELLEN at MIT-MC) Date: 01 Dec 1981 00:00 Subject: No subject Message-ID: On MC, when a new user logs in INQUIR no longer queries him to fill it out. From ELLEN at MIT-MC Tue Dec 1 00:00:00 1981 From: ELLEN at MIT-MC (ELLEN at MIT-MC) Date: 01 Dec 1981 00:00 Subject: Previous message about INQUIR Message-ID: Sorry, never mind, I just realized that someone had deleted the * LOGIN file on the GUEST0; directory on MC, which is what was calling INQUIR. From SWG Tue Dec 1 00:00:00 1981 From: SWG (S. W. Galley) Date: 1 Dec 1981, 00:00 Subject: [Re: BUG => itsfgsbsdm's] In-Reply-To: <[MIT-DMS].216669> Message-ID: <[MIT-DMS].216742> I set DM's T00 width to 80. in TTYTYP 238.