[comp.unix.microport] 3.0e terminfo

vjs@calcite.UUCP (Vernon Schryver) (10/31/88)

Vnews, from news 2.11.14, does not work very will with the Microport
3.0e/DOS Merge at386 terminfo entry and kernel drivers.  In particular,
control-P and control-N mess up the screen, at least when vnews has been
compiled with STATOP to put the status at the top.

After spending far more hours than the end (vnews) justified, I've found the
following problems with the capabilities in the 3.0e/DM at386 terminfo entry:

vpa     is broken in the driver.  The sequence ^[[0d gets you to the 2nd
	line of the screen, as does ^[[1d, while ^[26d gets you to line 25.
	One might use %?.  vpa=\E[%i%p1%d;H is an easy work around, costing
	1 char.

csr	is broken in the driver.  ^[x;yr fails the test on page 17 of
	terminfo(4) as a 'destructive scrolling region (line the VT100)'.
	It fails because ^[S does not blank the bottom of the region,
	just as the bad things in vnews should have told me hours ago.  I
	think it is necessary to delete csr from the terminfo entry.
	This may not help someone trying to emulating VT100's.

is1     may be broken.  It leaves garbage on the screen.  It seems possible
	that it was meant to be is2=\E7\E[r\E8\E[?6l\E[?7l instead of
	is2=\E7\E[r\E8\E[?6;?7l  At least that fixes the cruft.

rs1	has an extra ';' after the '\Ec' that makes a screen dropping.
	rs[123] will not restore all possible bad states (see below).

rs2	is simply crazy, or I can't read.  Page 14 of terminfo(4) implies
	rs{1,2,3} do not get any parameters.  However, the 3.0e version
	uses both %p1 and %p2.

??	one of the reset or initializing strings should include \E[4l.  It
	is a puzzle to escape the \E[4h mode, unless you cheat and read
	ansi(7).  None of the existing [ir]s[123] seem to do it.  You can
	get things total confused by echoing garbage.  Resetting is not
	useful unless it starts with \E13l, since nothing works until ESC
	does.  It seems useful to have is1=\E[13l\E[3l\E[4l\E[10m\E[=h
	to clear ALL wierd modes.  Similarly, rs1 should start with \E13l

cub1, cud1, rms0, rmul are longer than necessary, which does not matter
	unless you use cu(1) to talk to a remote machine, which you have
	told to use a terminfo/termcap entry matching your screen.  In
	those circumstances, extra bytes=extra time=lost performance.

If you use infocmp to unpack the standard version, beware that infocmp
will change kdch1 from \177 to ^?, which tic will convert to ^_.  That is,
infocmp and tic are not inverses of each other.  You have to edit the
result of infocmp to restore kdch1=\177.  (It looks to me like a bug in tic.)

I tried this in B&W.  I will not guess what these changes might do to color.
As always, you should read the manuals and check it out yourself before
doing as I say; don't trust bozos in the netnews.  Start with terminfo(4),
ansi(7), and display(7).  Use the TERMINFO enviroment variable so you don't
have to change the real stuff in /usr/lib.

Vernon Schryver
vjs@calcite.uucp  or   {decwr,pyramid,sun}!sgi!calcite!vjs

vjs@calcite.UUCP (Vernon Schryver) (10/31/88)

In article <28@calcite.UUCP>, vjs@calcite.UUCP (Vernon Schryver) writes:
> Vnews, from news 2.11.14, does not work very will with the Microport
> 3.0e/DOS Merge at386 terminfo entry and kernel drivers.  ...

In addition:
rep	works, but not the way curses/terminfo expects.  The cursor
	is left after the 1st character, and before the n-1 repetitions.
	This breaks version 4.87 of moria or 'umoria'.  It is best to 
	delete rep, along with csr and perhaps vpa.

Vernon Schryver
vjs@calcite.uucp  or   {decwr,pyramid,sun}!sgi!calcite!vjs