Xref: utzoo comp.windows.x:38060 comp.windows.open-look:1803
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!olivea!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.windows.x,comp.windows.open-look
Subject: Re: Is there an X-enhanced `vi' ??
Message-ID: <8591@auspex.auspex.com>
Date: 27 Jun 91 17:25:04 GMT
References: <1991Jun25.135342.11766@aifh.ed.ac.uk> <1991Jun26.073534.8343@twinsun.com> <1991Jun26.183613.10185@twinsun.com>
Followup-To: comp.windows.x
Organization: Auspex Systems, Santa Clara
Lines: 32

>I got this story from a Sun maintenance engineer, but I've since been
>informed that it's a garbled version of reality.

So's the followup....

>SunOS versions up through 4.0.x used Berkeley vi, which tries to handles
>window resize events although it mishandles some cases.

The 4.3BSD "vi" handles window resize, sort of, but botches it.

SunOS prior to 3.2 used the 4.2BSD "vi", which didn't handle resize at
all.  The "vi" was upgraded to the 4.3BSD version in 3.2, but the
resizing code was removed due to the aforementioned botches (somebody
filed a bug report because, when they exposed a "shelltool" window that
was running a "vi" that was reading in a file, the magic "longjmp"
aborted the readin with no warning).

>Starting with version 4.1, SunOS uses System V vi, which has never
>handled window resizes.

True, but the SunOS "vi" has never handled window resizes, period.  Had
the BSD version done so sanely, the BSD changes to do so would have been
put into the S5R3.1 "vi" for 4.1.

>Because of this botch, many folks save 4.0.3 vi and reinstall it under
>the 4.1 OS.

If they do so, they aren't going to get any better handling of window
resizes; they'd better build the 4.3BSD "vi" and run *that* instead if
they want window resizing (and had better be prepared to be rudely
surprised if the SIGWINCH is delivered while "vi" is actually doing
work).