Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!UTKCS2.CS.UTK.EDU!moore
From: moore@UTKCS2.CS.UTK.EDU (Keith Moore)
Newsgroups: comp.emacs
Subject: Re: termcap, flow control, emacs
Message-ID: <8706250125.AA28132@UTKCS2.CS.UTK.EDU>
Date: Wed, 24-Jun-87 21:25:12 EDT
Article-I.D.: UTKCS2.8706250125.AA28132
Posted: Wed Jun 24 21:25:12 1987
Date-Received: Sat, 27-Jun-87 03:11:12 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 24

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@utkcs1