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