Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!pegasus!hansen
From: hansen@pegasus.UUCP (Tony L. Hansen)
Newsgroups: net.bugs.4bsd,net.info-terms
Subject: Re: Using "am" or "xn" in programs considered harmful
Message-ID: <2823@pegasus.UUCP>
Date: Sat, 23-Aug-86 00:15:40 EDT
Article-I.D.: pegasus.2823
Posted: Sat Aug 23 00:15:40 1986
Date-Received: Sat, 23-Aug-86 23:40:08 EDT
References: <3864@utah-cs.UUCP> <925@hoptoad.uucp> <2753@mit-eddie.MIT.EDU> <958@hoptoad.uucp>
Reply-To: hansen@pegasus.UUCP (62545457-Tony L. Hansen;LZ 3B-315;6243)
Organization: AT&T-IS Labs, Lincroft, NJ
Lines: 62
Keywords: termcap,terminfo,curses
Summary: how curses makes use am,xn
Xref: mnetor net.bugs.4bsd:895 net.info-terms:558

< Aha!  The problem is coming out!
< 
< Some people (Doug Gwyn for example) think "am" means this:
< 
< ...
< 
< On the other hand, Barry Margolin points out that "Applications need to
< know whether they can safely output to [column 80 of the last line]
< without causing the screen to scroll."  The above definitions provide
< no guidance about this; so some software appears to be assuming:
< 
< 	am@	terminal stays in col 80 after printing char there
< 
< This is the problem I've been facing.
< 
< So, let me modify my suggestion.  If "am" is set, you can assume that
< the cursor will move to the next line.  If "am" is not set, **you must
< not assume anything**.  In either case, you can't safely write to column
< 80 of the last line.
< 
< This would mean that removing "am" from a termcap entry would never
< cause it to fail.  That is what I am after.

I think it would be instructive to look at how the curses library assumes
that the am/xn interaction is supposed to work.  Taking a 24x80 terminal as
an example, after writing a character into the 80th column:

System Vr2 curses library:

am@, xn@	it assumes that the cursor has remained in the 80th column.
am, xn@		it assumes that the cursor has wrapped to the beginning
am, xn		it assumes that one of two things has happened:
		(vt100 like)
		the cursor is still in column 80 (or a mythical column 81)
		and would go to the beginning of the next one on the next
		character output
	or
		(concept like)
		if the next characters output are <CR> or <NL>, they will
		be ignored

		To handle both of these cases, it outputs <CR><NL> to force
		the cursor to go to the beginning of the next line.

The 4.2BSD curses library doesn't check xn at all, even though it does pull
in the flag from the termcap entry. If am@, it outputs <CR><NL> to force the
cursor to the beginning of the next line; otherwise it seems to assume that
the cursor has gone to the beginning of the next line on its own. (I can't
really check this out on a real 4.2 system because all of the 4.2 systems
that I have access to have converted to the System Vr2 terminfo-based
curses.

By the way, regarding placing a character into the last column (call it the
80th column) of the last line, the way that the System Vr3 curses library
handles this problem is to place the character that belongs in the 80th
column into the 79th column. It then moves back to the 79th column and
INSERTS the character that belongs in the 79th column, forcing the correct
character into the 80th column without causing the screen to scroll. If the
terminal can't do insert, it leaves the 80th column blank.

					Tony Hansen
					ihnp4!pegasus!hansen