Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!mcsun!ukc!acorn!john
From: john@acorn.co.uk (John Bowler)
Newsgroups: comp.windows.x
Subject: Re: how does xterm tell vi the window size
Keywords: xterm vi
Message-ID: <1055@acorn.co.uk>
Date: 6 Oct 89 14:51:57 GMT
References: <253@zeek.UUCP> <1227@virtech.UUCP> <286@enuxha.eas.asu.edu> <1233@virtech.UUCP>
Reply-To: john@acorn.UUCP (John Bowler)
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 98

The mechanism used by vi, and most other termcap (and terminfo?) based
programs, to find out how big the window is simply doesn't work
adequately on systems with variable sized windows (eg xterm windows).
On BSD systems (including Sun OS) what vi does goes something along the
lines of:-

	1) Look in the environment (getenv(3)) - is there a TERMCAP?
		Yes - use the values of the ``co'' (columns) and ``li''
			(lines) parameters if they exist.
		No - if there is a TERM variable look that up in the
			termcap (terminfo on Sys V) database and use
			that information.

	2) If the number of columns or lines is still not known, use
		BSD specific ioctl's to attempt to find the column and
		line values from the *new* tty driver.  If the old tty
		driver is being used this fails, if not, and the columns
		and lines values are non-zero use these.  (See tty(4) on
		a BSD system).  Since pre-R4 System V systems only have
		the old (version 7) tty driver this mechanism can't
		be used on System V (until release 4).

	3) If the columns or lines value is still zero, complain about
		the terminal being too dumb (and give up - vi goes into
		ex mode).

If the new tty driver is in use then vi may receive a SIGWINCH while it
is running - in this case it resizes its window (within certain limits -
try using the ``micro'' font and zooming the window to full screen).

The problem is that the standard ``xterm'' termcap (or terminfo) entry
has co#80:li#24 entries (ie 80 columns, 24 lines).  These entries are
picked up at stage (1) above, and vi does not see if the terminal
driver has any opinion.  The ``resize'' program does not really fix the
problem - it allows you (the user) to generate new TERMCAP entries and
put them into your environment, but these still become incorrect
whenever the window size is changed.  Our (Acorn's) approach to this
problem is to distribute the following ``xterm'' /etc/termcap entries
(NOTE - this ONLY works on BSD systems with the new tty line driver, and
read the other comments below the entry before using it...)

X0|xterm-24|vs100s|xterm terminal emulator (small)(X window system):\
        :co#80:li#24:tc=xterm:
X1|xterm-32|vs100|xterm terminal emulator (medium)(X window system):\
        :co#96:li#32:tc=xterm:
X2|xterm-45|vs100-w|xterm terminal emulator (large)(X window system):\
        :co#144:li#45:tc=xterm:

# Following contains a major fixup to make xterm work semi sensibly - the
# ``co'' and ``li'' entries are commented out so that xterm can still see
# them but doesn't actually set anything useful.  It also contains an am
# (auto-margin) flag and has an im/ei/mi sequence instead of the ic one
# (this makes things faster on our system).
#
AX|xterm|xterm terminal emulator (X window system):\
        :.co#80:.li#24:cr=^M:do=^J:nl=^J:bl=^G:le=^H:ho=\E[H:\
        :cl=\E[H\E[2J:bs:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:\
        :ce=\E[K:cd=\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:\
        :md=\E[1m:mr=\E[7m:me=\E[m:\
        :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\
        :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:ta=^I:pt:sf=\n:sr=\EM:\
        :al=\E[L:dl=\E[M:im=\E[4h:ei=\E[4l:mi:dc=\E[P:\
        :MT:ks=\E[?1h\E=:ke=\E[?1l\E>:\
        :is=\E[m\E>\E[?7h\E[?1;3;4l\E[2;4;12;20l:\
        :rs=\E[r\E<\E[m\E[2J\E[H\E>\E[?7h\E[?1;3;4;5;6l\E[2;4;12;20l:xn:\
        :AL=\E[%dL:DL=\E[%dM:IC=\E[%d@:DC=\E[%dP:\
        :ti=\E7\E[?47h:te=\E[2J\E[?47l\E8:\
        :hs:ts=\E[?E\E[?%i%dT:fs=\E[?F:es:ds=\E[?E:am:

This causes the first step above to fail.  This works for vi (which
understands the new tty driver) but does *NOT* work for some versions
of emacs and some games - such programs skip step (2) above.  This is
the reason for providing xterm-24 and so on.  Notice that the
``resize'' command will not work (correctly) with the xterm entry above
(because it edits .co and .li entries, but does not remove the dots!)

Of course the ``correct'' solution is for all programs to use the new
tty line driver and to get the display size from it - but I cannot see
this happening in the near future.  As if this isn't bad enough one
extra problem arises when using rlogin.  Rlogin trys to transfer the
terminal characteristics to the other end of the pseudo-tty (so that
the device which the remote program talks to sees a terminal with the
same characteristics as that on which its output is displayed).  To do
this both rlogin and the daemon it talks to must agree.  In practice
this works if you rlogin between machines running the same version of
the same operating system, but sometimes fails when working between
different machines with different operating systems.

To make this worse login, in an apparent attempt at security, cleans
the characteristics of the new tty line driver (setting rows and
columns to 0) when it starts up a (Unix) session.  Thus xterm -L used
to result in a pseudo-tty with 0 rows and columns (even though xterm
*did* set them correctly).  It is also one reason for the tset
aberration - the correct tset command (in a .profile or .login)
restores the terminal line characteristics which (in the ideal world)
would be put in place by getty/xdm/xterm/whatever.

John Bowler (jbowler@acorn.co.uk)