ford@crash.CTS.COM (Michael Ditto) (06/20/87)
In article <5988@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Railing against the use of DC3 and DC1 for flow control by some terminals >is pointless [...] No, it is like fighting against slavery or aparthied or sex discrimination; after we are rid of them, people will think "gee, remember when people used to have slaves, when women coudn't vote, when in-band flow control was used?" (ok, exaggeration admitted). In-band flow control is necessary because of ancient protocols (like voice-line modems) that can not have out-of-band flow control. But we people who know better can still complain and choose more intelligent alternatives when they are available. >If your terminal requires support for DC3/DC1 flow control, you should so >inform the UNIX terminal handler, which will make sure the DC3/DC1 >characters are not seen by the application. You should also have the "xo" >Boolean capability set in the termcap entry. If in spite of this, your >copy of EMACS nonetheless persists in receiving DC3/DC1 and treating them >as user command keystrokes, then your EMACS is in need of repair. I find it very convenient to have XON/XOFF flow control enabled when I am not in Emacs, it allows the terminal to keep up with output from normal commands. But in Emacs, this is useless, as never more than a screenful of output is given. Therefore, it makes sense for Emacs to DISABLE XON/XOFF in the terminal driver. If someone has a terminal that is so losing as not to be able to receive and display one screen of text without flow control, Gnu-Emacs (why would anyone use anything else?) allows flow control to be activated by the expression (set-input-mode nil t) in the .emacs file. The method of flow control is not really related to the protocol for cursor motion, etc., so an 'xo' capability is silly. Flow control is at a different level of communication protocol than termcap. Editors should use the tty driver's current flow control information if they have a need to be aware of flow control methods (and they normally shouldn't). > [...] (You should also get out >of the habit of using any key bindings containing ^S or ^Q. That was a >really stupid set of defaults in the first place.) Again, I feel that the ancient protocols should not be encouraged in any new products. Allthough Emacs should (and does) give a way for old-fashioned terminals to work, there is no need for the default command set to be crippled because of it. Also, part of the "definition" of an Emacs editor is its "standard" Emacs command set as originally designed, and passed down through the generations of hackers. -- Michael "Ford" Ditto -=] Ford [=- P.O. Box 1721 ford@crash.CTS.COM Bonita, CA 92002 ford%oz@prep.mit.ai.edu
eichin@ATHENA.MIT.EDU ("Mark W. Eichin") (06/21/87)
>From: Michael Ditto <ucsdhub!jack!man!crash!ford@SDCSVAX.UCSD.EDU> >Again, I feel that the ancient protocols should not be encouraged in any >new products. ... Later, > ... Also, part of the "definition" of an Emacs editor >is its "standard" Emacs command set as originally designed, and passed down >through the generations of hackers. Doesn't this make the emacs commandset one of these "ancient protocols"? ( :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) Really, wasn't one of the reasons for ^s/^q to be in-band was so that they could be generated by the user? At least in the CP/M micro world, they were used as flow control for the USER, not just the terminal. The standard way for a user to pause output in order to have time to read it was to hit ^s. 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? /Happy Hacking........\\.............Mark Eichin/ <eichin@ATHENA.MIT.EDU><SIPB member & Watchmaker>
JNTCS@UNO.BITNET (06/21/87)
Michael Ditto <ucsdhub!jack!man!crash!ford@SDCSVAX.UCSD.EDU> writes > [...] But in Emacs, this is useless, as never more than a screenful of >output is given. Therefore, it makes sense for Emacs to DISABLE XON/XOFF in >the terminal driver. If someone has a terminal that is so losing as not to >be able to receive and display one screen of text without flow control, > [...] Yes, Emacs never outputs more than a screen at a time, but ... 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 and sends ^S/^Q because it's too slow (even in jump scroll), 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 . Also not all systems allow the disabling of ^S/^Q . I'm running under VMS on a LAT (a terminal concentrator on ethernet), and DEC has somewhy decided that the LAT should pay attention to all special terminal modes EXCEPT the one that turns off ^S/^Q . Sigh! And then, "Mark W. Eichin" <eichin@ATHENA.MIT.EDU> 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? 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. The older terminals didn't have these niceties. And one of the great things about the original Emacs was that it really worked hard at using what was already on the screen. James N. Thomas alias list: Jim, Nothead Computer Science BITNET: JNTCS@UNO.BITNET university of new orleans maBell: (504) 286-6754 New Orleans LA 70148 motto: Aloha!
rlk@.COM (Robert Krawitz) (06/22/87)
In article <8706211844.AA16179@FYUNCH.MIT.EDU> eichin@ATHENA.MIT.EDU ("Mark W. Eichin") writes:
]Really, wasn't one of the reasons for ^s/^q to be in-band was so that
]they could be generated by the user? At least in the CP/M micro world,
]they were used as flow control for the USER, not just the terminal. The
]standard way for a user to pause output in order to have time to read it
]was to hit ^s.
That's OK, in scrolling situations the user should be able to stop
output, whether with C-s or something else. But it should be under
the user's control, and the user should not be forced to assume
C-s/C-q are always for flow control (it makes no sense in emacs, for
example). It works fine for user flow control. Not so good for
terminal flow control, though...
]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?
VT52's run just fine, as do AITV's. The AITV system used bitmap
screens with 9-bit keyboards (Lisp Machine modulo super and hyper
keys). Considering the people that hacked back then, if they'd been
forced to use equipment forcibly using XON/XOFF flow control, they'd
have hacked it so it wouldn't have.
Emacs didn't start off as someone saying "Let's write emacs from
scratch" (look at the name). It originally was various macro packages
in Teco under ITS, and then RMS and a few others banged it into shape.
At that time, probably no one ever thought of it as a commercial
product, and so no one saw any real need to make it work with
commercial equipment.
Robert^Zmly@PREP.AI.MIT.EDU (Richard Mlynarik) (06/23/87)
From: eichin@ATHENA.MIT.EDU ("Mark W. Eichin")
Date: 21 Jun 87 18:44:36 GMT
References: <1263@crash.CTS.COM>
Really, wasn't one of the reasons for ^s/^q to be in-band was so that
they could be generated by the user? At least in the CP/M micro world,
they were used as flow control for the USER, not just the terminal. The
standard way for a user to pause output in order to have time to read it
was to hit ^s.
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?
What pathetic brain-damaged equipment are your using here in the
future which won't let you `get away with it?' You should probably
throw it away --- one could do better than that fifteen years ago.
(But then again, we're using un*x...)chris@mimsy.UUCP (Chris Torek) (06/24/87)
>And then, "Mark W. Eichin" <eichin@ATHENA.MIT.EDU> 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
moore@UTKCS2.CS.UTK.EDU (Keith Moore) (06/25/87)
In article <7182@mimsy.UUCP> Chris Torek <chris@MIMSY.UMD.EDU> writes:
...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. ...
Many of our dialup terminals here use such a terminal server. My solution
has been to use 'stty 1200' (on Unix) or 'set term/speed=1200' (on VMS)
to un-fool the host's idea of the baud rate. This might not work for
everyone, though.
For those of us using GNU emacs, it should be easy to add a lisp variable
called effective-baud-rate, which, though initialized to the terminal's
baud rate as seen by stty, could be changed by user- or site-specific
code. The effective-baud-rate would then be used in screen updating
calculations.
Keith Moore Internet: moore@utkcs2.cs.utk.edu
University of Tenn CS Dept CSnet: moore@tennessee
Knoxville TN BITNET: moore@utkcs1scott@cdp.UUCP (06/29/87)
By the way, turning off Ignore NUL (and hitting SETUP x) on the Ann Arbor Ambassador is very useful for checking to see if software is *really* sending the NULLs it's supposed to send. -scott
james@cantuar.UUCP (J. Collier) (07/02/87)
Some terminal emulators automatically send Xoff/Xon pairs when local
actions - such as a menu seletion to re-define mouse-click interpretation -
are invoked.
This is clearly undesirable in emacs, but may be necessary elsewhere.
If the terminal/emulator has a flow control disabling sequence, GNU-emacs users
may find the following ".emacs" entries of use:
(send-string-to-terminal "<disable sequence>")
(defun t925-suspend nil
(interactive)
(send-string-to-terminal "<enable sequence>")
(suspend-emacs)
(send-string-to-terminal "<disable sequence>") )
(defun t925-kill nil
(interactive)
(send-string-to-terminal "<enable sequence>")
(save-buffers-kill-emacs) )
(global-set-key "\C-x\C-z" 't925-suspend)
(global-set-key "\C-x\C-c" 't925-kill)
[No flames if there's an easier way, please; I am not a regular emacs user]
BTW is it my imagination, or does GNU-emacs (v17.64) not know the difference
between the "in" and "im" insert-mode styles for 4.3BSD termcap? Having gone
to some trouble to add "im" to my pet terminal emulator, I now find I must
disable the termcap entry for emacs's pleasure. What gives?
-------------------------
James Collier (james@cantuar.uucp / {watmath,munnari,mcvax}!cantuar!james
Computer Science Dept., University of Canterbury, Christchurch, New Zealand.GZT.FORD@OZ.AI.MIT.EDU (07/20/87)
> [...] > Doesn't this make the emacs commandset one of these "ancient protocols"? Yes, but I think there is a distinction between user-interface commands and communication protocols. The canonical use of ^S as a user-generated pause command such as is built-in to CP/M is most likely just a result of people who were used to typing the low-level flow control characters when using serially-connected terminals. Anyway, it's all just the facts of life now; we can only hope to remember the confusion it all caused when designing new systems. Happy hacking! -=] Mike "Ford" Ditto [=- usenet: ford@crash.CTS.COM arpa: ford@oz.AI.MIT.EDU