Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!mit-eddie!bu-cs!bzs From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.sources.d,comp.terminals Subject: Re: VT100's keeping up at high baud rates Message-ID: <8959@bu-cs.BU.EDU> Date: Mon, 22-Jun-87 19:13:13 EDT Article-I.D.: bu-cs.8959 Posted: Mon Jun 22 19:13:13 1987 Date-Received: Sat, 27-Jun-87 04:09:28 EDT References: <1149@carthage.swatsun.UUCP> <8601@tekecs.TEK.COM> Organization: Boston U. Comp. Sci. Lines: 34 Xref: mnetor comp.sources.d:898 comp.terminals:330 In-reply-to: wcs@ho95e.ATT.COM's message of 16 Jun 87 22:16:22 GMT Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix) From Bill Stewart >There are two real issues here - how fast can a terminal go with flow control >enabled, and how fast can it go with flow control disabled. While it's nice to >have a terminal that can keep up with 19200 without flow control (i.e. >continuous text display), that's approximately 19200 words per minute, and >neither you nor I nor Evelyn Wood's mother can read that fast over sustained >periods. The reasons you'd want a terminal to go that fast without flow >control are either that you use a braindamaged computer which can't handle it, >or that you're using EMACS, and flow control ^S puts you into search mode. >(The solution there is to fix the software.) I doubt you could read a terminal running at 1200b for a sustained period of time, yet I'd bet you prefer a higher speed. Why? Because there's more going on, many screenfuls contain little information but need to put up the entire screen because it's too hard to predict what you need in advance and/or the rest of the image creates a context. Two good examples of this are Emacs' incremental search where often a squinty-eyed view of the screen tells you you need another screenful (eg. looking for a function definition, you don't need to even focus your eyes to see you haven't found it yet in most languages) and games (ok, maybe not the most serious application, but I think it's an example of something.) Also, given the higher speed updates more visual information can be built into applications rather than trying to minimize screen update (such as drawing boxes around relevant items, using screen attributes like bold and blinking etc.) Any of this gets painful at even the faster screen speeds real quick. Here's to human factors engineering. It's subtle. -Barry Shein, Boston University