why doesnt vi resize itself in xterm and other weirdness
Sean Eric Fagan
sef at kithrup.COM
Sun Jan 13 21:04:40 AEST 1991
In article <37871 at cup.portal.com> DeadHead at cup.portal.com (Bruce M Ong) writes:
>Hi -
> I am playing around with a big monitor (corner stone) on the
>ISC2.2 unix. The resolution is 1600x1024 or something. I have a vi
>running in an xterm, but when I resize the xterm and restart vi,
>it will not chanage its window size according to the size of xterm. My
>TERM is set to xterm. Why is this so? My sparc station doesnt seem to do
>this at all.
Your TERM variable, in this case, doesn't matter. Under BSD-based systems
(and some SysV systems, but not all, by any means), resizing a window causes
the window program (xterm, in this case) to send a SIGWINCH to the process
group running in that window; if the program has been written to accept it,
it will then do an ioctl(fd, TIOCGWINSZ, &buf) to get the size of the
window. (I think that's the ioctl.)
However, SysV does not have this for normal pseudo-tty's (which is what most
xterms use). The STREAMS-based ptys, which are unsupported (and, I believe,
undocumented), *do* support the necessary ioctl, but I don't know of any X
implementation that uses them.
> Another problem is that if you do rlogin and then vi on the
>remote machine from an xterm, the vi window is always 25x80 no matter
>what size your xterm is. Is there anything I should fix in xterm termcap?
export LINES=<lines> COLUMNS=<rows>
SCO ships a program called resize, which I tend to use as
eval $(resize)
(I use ksh); this spits out a TERMCAP, I believe, as well the LINES and
COLUMNS variables. (I don't know if resize is a standard program or not.)
Note, however, that you would have to quit vi to take advantage of a resized
window.
--
Sean Eric Fagan | "I made the universe, but please don't blame me for it;
sef at kithrup.COM | I had a bellyache at the time."
-----------------+ -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.
More information about the Comp.unix.sysv386
mailing list