Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: net.bugs.4bsd,net.info-terms
Subject: Using "am" or "xn" in programs considered harmful
Message-ID: <925@hoptoad.uucp>
Date: Wed, 30-Jul-86 21:42:41 EDT
Article-I.D.: hoptoad.925
Posted: Wed Jul 30 21:42:41 1986
Date-Received: Thu, 31-Jul-86 21:13:15 EDT
References: <3864@utah-cs.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 37
Xref: mnetor net.bugs.4bsd:843 net.info-terms:543

In article <3864@utah-cs.UUCP>, donn@utah-cs.UUCP (Donn Seeley) writes:
> Subject: 'more' doesn't understand 'xn' type terminals (such as 'xterm')

I propose that the termcap fields "am" and "xn" be deprecated and
that programs be written to ignore these fields.  I've been discussing
this with Ken Arnold (for Curses) but I don't know if he's convinced yet.

The problem is that "am" is particularly hard to get right in a termcap
entry.  Often (eg VT100) it depends on physical switch settings which
cannot be changed by escape codes and cannot be read by the program.
Many terminal emulators also have this ("Line Wrap") as a settable option.
I have seen more termcap entries that were "almost right" except for "am",
than any other termcap entry problem.

The reason I think it's a good idea to blow them away is that they
don't buy much.  They only come into play when a character is written
into the last column of the screen.  That's a very infrequent
condition.  Even when it happens, what is saved is a cursor positioning
command.  (Trusting "am" lets the program assume where the cursor will
be; not trusting it means you have to actually move the cursor to where
it should go next.)  If your program (e.g. "more") is outputting lines
of text, in the infrequent case that a line hits the 80th column, it
will have to print 80 chars and then a cursor positioning escape code,
rather than 80 chars, CR, and LF; or 80 chars and nothing.  Even if
the escape code is 8 bytes (some are), this is less than 10% overhead
in an infrequent case.

What you get back for your occasional <10% slower long line is that
your termcap entry is likely to be right, so that the long line will
actually appear in the right place and not mess up the screen display.

(While I recommend that programs not use "am" and "xn", I realize
that until the programs are all fixed, we will have to keep trying
to build termcap entries that get them right, when possible.)
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa
		     May the Source be with you!