3.0e display bugs

[Vernon Schryver]

I have previous written that some of the 3.0e terminfo entries and/or
the driver are in need of improvement.  I have noted that vpa, csa, and
rep are broken in the driver.  is1, rs1, rs2, cub1, cud1, and rms0
could be defined more robustly, completely, or efficiently.

In addition, <smir> (enter insert mode, '\E[4h') and/or <ich> (insert
characters, '\E[n@') are broken in the driver, or at least does not
work as curses(3) expects.  Under some circumstances, umoria 4.48 likes
to modifiy the window to cause curses to emit the sequence
<smir><ich<n>><rmir> when curses(3) refreshes it.  That is, it enters
insert-mode, inserts some characters and then exits insert mode.  One
might expect that curses(3) would either enter insert mode and emit
blanks or insert characters, but not both.  However, it does as I say.
Unfortunately, the Microport driver does not like to do it that way.
While in insert mode set by '\E4[h', it ignores '\E%d@'.  All of this
sounds to me like a functional bug in the Microport 3.0e emulator as
well as an efficency bug in the SVR3.0 curses.

One technique that seems useful for finding and diagnosing these problems,
usually without hacking the source, is to
 (1) run the suffering program on one virtual console,
 (2) send all 3 sequences necessary for 'monitor mode' to that console
	from a different virtual console,
 (3) repeat the problem, to find the sequences curses(3) is sending,
 (4) given an hypothesis, send sequences to yet another virtual console,
	to verify that one has indeed isolated some bogus behaviour,
 (5) either reboot or read display(7) and ansi(7) very carefully to
	restore the target virtual consoles.

Vernon Scrhyver
{sgi,pyramid}!calcite!vjs