Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site desint.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.info-terms
Subject: Re: autowrapping terminals
Message-ID: <162@desint.UUCP>
Date: Sat, 20-Oct-84 16:01:16 EDT
Article-I.D.: desint.162
Posted: Sat Oct 20 16:01:16 1984
Date-Received: Mon, 22-Oct-84 15:32:57 EDT
References: <459@uwvax.UUCP> <5084@brl-tgr.ARPA> <194@bragvax.UUCP>
Organization: his home computer, Thousand Oaks, CA
Lines: 89
Keywords: autowrap, automatic margins
Summary: No program can safely make may assumptions about autowrap
Let me see if I can summarize the various flavors of terminal autowrapping I
have seen or seen described (terminology is my own; I invite more reasonable
suggestions):
(1) NO WRAP WHATSOEVER. When the cursor reaches column 80, it stays
there, no matter what. Subsequent characters overwrite column 80.
CR/LF produce the same behavior they would on a terminal of infinite
width, given the same character stream.
(2) "LAZY" AUTOWRAP. When a character is written in column 80, the
cursor immediately wraps to the following line. CR/LF produce the
same behavior you would get on a terminal of infinite width if the
cursor were in the same column at the moment of receiving CR/LF.
The disadvantage of this approach is that you cannot write line 24,
column 80 (okay, 66/80 for you lucky ones with *usable* terminals)
without scrolling the screen.
(3) "SINGLE-SPACED" AUTOWRAP. When a character is written in column 80,
the cursor remains there, but an internal flag is set. If the next
character received is a printing character, the cursor is wrapped
BEFORE the character is written to the screen (on column 1 of the
following line). This has two advantages: you can write 24/80
without scrolling the screen, and 80-character lines do not show up
double-spaced. Of course, from an editor's point of view this
behavior can be thought of as eating the newline that follows an
80-character line; hence "eat_newline_glitch". (But see #4).
There has also been discussion on the net of various ways a
terminal can respond to leftwards-motion commands when the cursor
is in column 80 with the flag set. This can either work exactly
like there really was a column 81 ("virtual column 81"
implementation) or in can work like the cursor was in column 80
with the flag clear ("no column 81" implementation). In any case,
it appears that there is no way to set the internal flag without
actually writing a character in column 80, and it is cleared as
soon as you leave (physical) column 80 by any horizontal motion.
My terminal (not a vt100) does *not* clear the flag if you give it
vertical motion commands, including "[12;80H"; on other
terminals the flag may be cleared in this case.
(4) "BRAINDAMAGED SINGLE-SPACED" AUTOWRAP. Operates like #2, "lazy"
autowrap, except that an internal flag is set that causes an
immediately following newline to be ignored. I have never
personally encountered a terminal that does this, but I infer
from termcap(5) [or wherever your version of Unix puts it] that
this is the behavior that is referred to by the "xn" capability.
This differs from #3 above in that you cannot write 24/80 without
scrolling the screen.
Note that there are a lot of variations here, especially when you consider the
sub-variations of #3. Technically, since :am: and :xn: are both Boolean,
we could encode four states, but we would be stretching the meaning of the
capabilities by a lot, and we still wouldn't be able to handle the
sub-variations in #3.
My suggestion is to give up on this theory that a full-feature termcap
program (with vi as the obvious example) should be able to make *full* use
of *every* terminal in the most optimal fashion possible. It's really neat
that vi will run at 300 baud without sending any excess characters across