Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.emacs Subject: Re: termcap, flow control, emacs Message-ID: <7182@mimsy.UUCP> Date: Tue, 23-Jun-87 18:16:38 EDT Article-I.D.: mimsy.7182 Posted: Tue Jun 23 18:16:38 1987 Date-Received: Thu, 25-Jun-87 03:56:43 EDT References: <8706212040.AA29804@ucbvax.Berkeley.EDU> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 76 >And then, "Mark W. Eichin" writes >>Given the age of the 'emacs' series of editors, why did they overload ^s >>even further? RMS, Gosling, anyone out there know? I would guess it was >>simply mnemonic for 'Search', but what equipment of that day let them >>get away with it? In article <8706212040.AA29804@ucbvax.Berkeley.EDU>, JNTCS@UNO.BITNET writes: >As I remember it, the VT05 may have been brain damaged in many ways, but it >could at least keep up with all of the characters sent to it. And I don't >think the VT52 ever sent any ^S's either. After all, what's slow in many >terminals is the "fancy" stuff like *smooth scroll* or insert/delete line. This is exactly right. Way-back-when, terminals never did ask the host to stop sending, for they could always keep up at the fastest rate at which they could receive. Flow control was purely a user action, and screen editors did not have to worry about user requested stops, since these editors would never write more than one screenful. [and, out of sequence---this was earlier]: >There are terminals that claim to have insert/delete line (etc.), >so people set termcap so that Emacs knows about these commands. >But then since the terminal doesn't really support insert/delete (Yes it does.) >and sends ^S/^Q because it's too slow (even in jump scroll), (It just supports it *slowly*.) >someone has to do something. I set the padding in termcap so that >all sorts of time and characters are wasted, but at least Emacs >never sees the ^S . If your Emacs is careful about cost calculations (as are James' and GNU's), no time or characters are wasted. With the proper amount of delay time listed in the termcap, Emacs accounts for an insert or delete cost *including* the required number of pad characters. Emacs will ignore the insert or delete feature whenever it is faster simply to rewrite the whole screen. At lower bit rates, it takes fewer characters to pause for the same amount of time, and the insert and delete features become useful, and hence used. New problems, however, have come up with new terminals and, more importantly, with network terminal servers. Some of the new terminals have no pad character (!) or make it optional (?!) (the Ann Arbor Ambassador has an `ignore NUL' option which, as far as I can tell, should never be turned off). Network terminal servers provide the `helpful' function of baud-matching, where the host computer can speak at a fixed baud rate, or with, e.g., TCP-based protocols at *no* baud rate, while the terminal server speaks to the terminal at a different rate. In essence, the server lies to the host computer about the terminal's baud rate. This wreaks havoc with time-per-pad-character-based delays. Fortunately, most RS232-based terminal multiplexor systems allow you to disable baud matching, so that the terminal and the host always speak at the same speed. (A notable exception is the AT&T ISN. You can turn off its flow control, but if you do so, it simply loses characters whenever the host and terminal baud rates do not match. The only solution is to make several different classes of multiplexor ports, one for each baud rate, and when using a terminal, ask for an `EE-Vax-at-9600-baud' port or an `EE-Vax-at-1200-baud' port depending on whether you are using a local terminal or dialling in. Or you can give in and let the ISN generate ^S/^Q flow control.) At any rate, as I have said before, all of these problems could be solved, and I would be unsurprised to find that certain universities with much in the way of spare resources have for their terminals their own ROMs, ones that use reasonable protocols and allow flow control without borrowing any valid input symbols. But until manufacturers agree on such a protocol, the rest of us are stuck with half-solutions. Do keep complaining, though: it is the only way things are likely to change. Complain---and point out solutions. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris