Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.terminals
Subject: Re: A Question About the Infamous VT100 Line Wrap Bug
Message-ID: <5559@brl-smoke.ARPA>
Date: Fri, 23-Jan-87 18:14:43 EST
Article-I.D.: brl-smok.5559
Posted: Fri Jan 23 18:14:43 1987
Date-Received: Mon, 26-Jan-87 01:40:54 EST
References: <1504@blia.BLI.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 34

In article <1504@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes:
>Could someone summarize the bug with vt100 terminals having
>to do with line wrapping. I recall it has something to do with
>what happens when a certain character appears in column 79 (80?).

Ok, here is a summary of what I am aware of about this.
The VT100 designers thought that it would be nifty if upon
receipt of the 80th character in a line during normal "glass
tty" operation, the cursor would stay positioned on top of
the 80th character instead of immediately scrolling a line
the way most auto-wrap features do.  I think their rationale
was two-part: first, that normally a carriage-return, line-feed
would follow, which would result in double-line spacing (unless
special handling were given to CRs just after an auto-wrap, as
I believe some newer terminals do); second, sometimes output is
"overstruck" (intended for printers), and auto-wrap would mean
that overstrikes would appear on separate lines (again, unless
special CR-after-auto-wrap handling were used); note that these
are essentially the same phenomenon.  In any case, the internal
firmware implementation (running on an 8085, I think) sets a
flag to keep track of the state when the 80th column is printed.
Unfortunately, under some circumstances the flag is not properly
handled by the firmware; this is most often seen when cursor
positioning is done to place characters in columns 80 and 1 of
various rows (eventually some end up in the wrong places).  The
only know fix for this is to treat the screen as only 79
characters wide (co#79 in termcap).

A related problem is that many VT100 termcap descriptions I have
seen specify "am" for the VT100.  This is absolutely wrong and
should be removed; if present, software is entitled to assume
that immediate (not deferred) auto-wrap occurs, which can cause
it to make errors in updating the VT100's display, since deferred
wrap doesn't act the same as real wrap under all circumstances.