home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!ames!sun-barr!cs.utexas.edu!zaphod.mps.ohio-state.edu!malgudi.oar.net!news.ans.net!cmcl2!adm!smoke!gwyn
- From: gwyn@smoke.brl.mil (Doug Gwyn)
- Newsgroups: comp.terminals
- Subject: Re: Vt320 Xon XoffHello,
- Message-ID: <19356@smoke.brl.mil>
- Date: 12 Nov 92 17:08:59 GMT
- References: <pmacdon.720998015@husc10>
- Organization: U.S. Army Ballistic Research Lab, APG MD.
- Lines: 20
-
- In article <pmacdon.720998015@husc10> pmacdon@husc10.harvard.edu (Philip Macdonald) writes:
- > This may be a FAQ but here goes anyway.
-
- Yes, it's a classic issue.
- Many modern ASCII terminals require host support for DC3/DC1 flow control
- in order to not overrun their input buffer while performing time-consuming
- operations such as insert line, smooth scroll, etc. The VT100 was the first
- widely used terminal like this.
- Unfortunately some of the EMACS hackers, Stallman for example, insisted
- that terminals should not behave that way and consequently refused (at
- least for a long time) to make their versions of EMACS properly support
- DC3/DC1 in-band flow control. For example, on most UNIX systems the user
- (or system administrator) is supposed to arrange for DC3/DC1 flow control
- to be handled by the operating system's terminal handler when the user
- logs in -- subsequent processes like EMACS then should preserve that mode
- when fiddling with the terminal handler settings for their particular
- style of screen and keyboard management. Unfortunately many such programs
- do not do this right (and some UNIX systems didn't support doing it right).
- I don't know which version of EMACS you have but there should be some way
- to force it to work right, even if it means editing the source code.
-