Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!wjh12!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.info-terms
Subject: Re: vt100, :am:, :xn:, :in:
Message-ID: <368@umcp-cs.UUCP>
Date: Tue, 16-Oct-84 21:19:24 EDT
Article-I.D.: umcp-cs.368
Posted: Tue Oct 16 21:19:24 1984
Date-Received: Sun, 21-Oct-84 10:21:23 EDT
References: <459@uwvax.UUCP> <5084@brl-tgr.ARPA> <194@bragvax.UUCP> <297@ptsfa.UUCP> <5339@brl-tgr.ARPA>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 64

*	From: gwyn@brl-tgr.ARPA (Doug Gwyn )

	> ... The only difference (problem) I've found so far is that
	> Crosstalk does not have/support the xn/xenl glitch in column
	> 80. It does wrap to the next line.  This is easy enough to turn
	> off, but I've also discovered that if you're inserting text
	> into a line which wraps to the next line, the second line
	> doesn't get displayed correctly.

	There is a common misconception about the VT100 and the xn/xenl
	capability; ... The wrapping upon character insert is
	independent of auto-margin and is supposed to be described by
	the "in" capability.

I think you're confused about what he's confused about, Doug.  [That
isn't confusing, is it? :-) ]  You might be right about what VT100s
should have in their termcap entries (but see below) but I don't think
he was talking about :in:.  Also, :in:  says nothing about the C-100
behaviour (where insertion in the middle of a single line may make it
become two lines), it merely says that insertion distinguishes
non-written locations from blanks, and thus all blanks within each line
must be written.  Vi may also assume that it implies that insertion
within a full-sized (80 characters or whatever your screen width is)
line makes the line "split" over two screen lines, but I haven't seen
this in any termcap documentation.

Now back to the :am: & :xn: debate . . . :am: says that the terminal
has auto margins; that is, after writing a character in column 80
(assuming an 80 column terminal) the cursor is in column 1 of the next
line.  :xn: says that after writing a character in column 80, one
newline (CR/LF sequence really) will be eaten if nothing else is
written.  (This makes the terminal very nicely split long lines yet not
put blank lines after lines exactly 80 characters long.  It's a
feature!)

VT100s have neither behaviour.  Instead, after writing in column 80,
the cursor is in sort of a ``virtual 81st column''.  If you put out a
backspace, the cursor goes to column 80 (i.e., it doesn't move).  Same
for ESC[D.  For ESC[C (cursor right) the cursor stays in col. 81.  For
any printing character, the cursor immediately moves to col. 1 of the
next line, then you get the printing character (or tab) done, and then
the cursor moves to col. 2.  For line feeds and up & down motions in
col. 81, the cursor moves to the next or previous line and col. 80.

However, what vi does with a terminal with :xn: is that if the cursor
gets to column 80 (or whatever), it writes a CR/LF, to satisfy the
``newline eater bug'' [hmmm ... sounds vaguely familiar :-) ].
Therefore, if you write your VT100 termcap to contain BOTH :am: and
:xn:, vi should work.  If you use NEITHER, then vi may (should!) assume
that after writing a character in column 80, the cursor is still in
column 80, and that therefore, a backspace should move it to col. 79!
This is NOT what happens, so I think VT100 termcaps should have *both*
:am: *and* :xn:.

Now for my disclaimer: all of these features were tested out on a
Datamedia DT80/1 terminal, not a true DEC VT100, but I believe that
the internals are exactly the same (i.e., Datamedia is selling
repackaged VT100s).
-- 
(This mind accidently left blank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland