Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.windows.open-look
Subject: Re: Resizing xterms running vi
Keywords: Openlook, X11, xterm, vi
Message-ID: <4330@auspex.auspex.com>
Date: 11 Nov 90 03:20:26 GMT
References: <3391@ryn.esg.dec.com> <1990Nov9.192029.970@twinsun.com>
Organization: Auspex Systems, Santa Clara
Lines: 55

>vi on most other vendors' Unix workstations get this right -- I just
>tested it on DEC, Omron, SGI, and Sony.

In other words:

1) if you resize the window, "vi" will resize its display, *even when
   you're in insert mode*?

2) if you resize the window *while you're reading in a large file*, "vi"
   will politely wait until the read is finished before resizing the
   window, rather than just "longjmp()"ing out of whatever it's doing
   and re-entering the command loop, aborting the reading?

If so, then all of those vendors fixed one obnoxious misfeature (1.
above) and one nasty bug (2. above) in the 4.3BSD "vi"'s rather crappy
implementation of resizing.  If that's the case, one hopes they were
polite and fed the changes back to Berkeley....

If not, well, the Sun "vi" *and* those vendors' "vi"s are *both* broken,
just in different ways....

>But vi on a Sun workstation is still broken.

The reason we disabled the resizing at Sun when we picked up the 4.3BSD
"vi" is that 2) was a *very* nasty bug there, as SIGWINCH is delivered
to the process group of the terminal associated with a "shelltool"
whenever a SIGWINCH is delivered to the "shelltool" itself; this not
only happens when the window is resized, but also:

	when it's opened or closed (this is *definitely* a feature,
	*not* a misfeature, from my standpoint; it lets me use a
	simple-minded shell script running inside a "shelltool" rather
	than "mailtool" with its crappy "textedit"-based editor);

	when an obscured portion of the window is exposed (this is, as
	far as I can tell, completely useless).

In retrospect, either:

	1) calls to block the SIGWINCH should have been wrapped around
	   *every* part of "vi" that can't safely be aborted when the
	   window is resized, including, of course, reading or writing
	   files, global search and replace, etc.;

	2) the SIGWINCH handler should have been changed merely to post
	   an indication that the window size changed, and all those
	   places where "vi" is reading commands and can reasonably
	   conveniently redisplay the screen should check for such an
	   indication.

>Ironic, isn't it, given that vi's author is Sun's R&D VP?

No, not really ironic at all, given that wnj had long since abandoned
any active involvement with "vi"; I don't think he had anything to do
with adding the SIGWINCH stuff in 4.3.