Xref: utzoo comp.windows.x:38001 comp.windows.open-look:1792
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!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: <8571@auspex.auspex.com>
Date: 26 Jun 91 17:47:40 GMT
Article-I.D.: auspex.8571
References: <1991Jun25.135342.11766@aifh.ed.ac.uk> <1991Jun26.073534.8343@twinsun.com>
Followup-To: comp.windows.x
Organization: Auspex Systems, Santa Clara
Lines: 22

>`vi' wasn't designed for asynchronous input like resize events.  Some
>versions of `vi' resize automatically, but I've never seen it work in
>all cases; e.g. if you resize while typing `:' commands `vi' usually
>gets confused.  Sun even _removed_ from `vi' the autoresizing code that
>they received from AT&T, because they couldn't fix its bugs!

Did AT&T do it the gross sloppy stupid way Berkeley did it, i.e. "when
you get a SIGWINCH, 'longjmp' out of the command input loop and restart
the editor"?  That was *really* lovely - have fun resizing a window if
"vi" is in the middle of reading a file in!  (Or opening the window - the
SunView "shelltool" and possibly the XView one as well deliver a
SIGWINCH to the terminal's process group if a window is de-iconified;
that comes in handy if, for example, you have a mail reader that's just
a small shell script wrapped around Berkmail.  The SunView version of
"shelltool", in fact, delivers SIGWINCH if any part of a window becomes
*exposed*.

Yes, "vi" could check whether the size changed, and only do the
"longjmp" if it did.  It's *still* gross to do the "longjmp".

Also, "vi" handles SIGWINCH when it's in input mode by *blocking* the
signal, so it doesn't resize until you finish the input command.)