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