Using "am" or "xn" in programs considered harmful

Barry Margolin barmar at mit-eddie.MIT.EDU
Fri Aug 1 17:19:06 AEST 1986


In article <925 at hoptoad.uucp> gnu at hoptoad.uucp (John Gilmore) writes:
>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.
>
>...  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.

Unfortunately, this is not completely correct.  I don't recall if
termcap has a separate field for this, but most terminals that have
auto-wrap will also scroll the screen if a character is written into the
rightmost column of the last line.  Applications need to know whether
they can safely output to that cell without causing the screen to
scroll.

On Multics we have a simple solution for this: our video support
software never puts characters in the last column.  The only thing it
ever uses the rightmost column for is to position the cursor there after
if the user has typed exactly N-1 characters on the line.  If the user
then types another character the cursor will first be positioned to the
beginning of the next line before the character is echoed.

Even among terminals that do not have auto-wrap, there are
incompatibilities in the way the rightmost column works.  Most
significantly, what is the effect of a backspace following the output of
a character in column 80?  Some terminals have an imaginary "column 81",
and a backspace from there moves the cursor back to 80.  The VT100,
however, will move the cursor to column 79.  Thus, column 80 must be
special-cased, because <char><bs> doesn't have the same effect there as
in other columns.
-- 
    Barry Margolin
    ARPA: barmar at MIT-Multics
    UUCP: ..!genrad!mit-eddie!barmar



More information about the Comp.bugs.4bsd.ucb-fixes mailing list