gordonc@aifh.ed.ac.uk (Gordon Cameron (RA DAI)) (06/25/91)
Does anyone know of a version of `vi' available which executes satisfactorily under X11/Xview ?? (i.e. Resizes automatically on window resizes etc...) Thanks in advance Gordon Cameron, Dept. of AI, Edinburgh University e-mail : gordonc@uk.ac.ed.aifh
schoch@starnet.com (Steve Schoch) (06/26/91)
In article <1991Jun25.135342.11766@aifh.ed.ac.uk> gordonc@aifh.ed.ac.uk (Gordon Cameron (RA DAI)) writes: > >Does anyone know of a version of `vi' available which executes >satisfactorily under X11/Xview ?? (i.e. Resizes automatically on window >resizes etc...) The necessary hooks to do this are already in most systems. To have it work, your system must do several things right: 1) xterm must give a new window size to the pty with the TIOCWINSIZE (or something like that) ioctl. 2) The tty driver must give a SIGWINCH to the current process when it's winsize changes. 3) vi must trap the SIGWINCH and redraw. Most vi's do this. It will work correctly on BSD 4.3. The ioctl #define is different between BSD 4.3 and SunOS. One calls it TTYSIZE and one call it WINSIZE. I believe SunOS doesn't do number 2. This problem can be solved by making the xterm send the signal itself. Steve
eggert@twinsun.com (Paul Eggert) (06/26/91)
gordonc@aifh.ed.ac.uk (Gordon Cameron (RA DAI)) writes: >Does anyone know of a version of `vi' available which executes >satisfactorily under X11/Xview ?? (i.e. Resizes automatically on window >resizes etc...) `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!
guy@auspex.auspex.com (Guy Harris) (06/27/91)
>`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.)
guy@auspex.auspex.com (Guy Harris) (06/27/91)
>It will work correctly on BSD 4.3. The ioctl #define is different between >BSD 4.3 and SunOS. One calls it TTYSIZE and one call it WINSIZE. The "ioctl" #define is different betwen BSD4.3 and SunOS prior to SunOS 3.2; SunOS 3.2 introduced the 4.3BSD TIOC[GS]WINSZ "ioctl"s, although they weren't documented until 4.0. (The older SunOS "ioctl"s were TIOC[GS]SIZE.) >I believe SunOS doesn't do number 2. You must still be running SunOS 3.0 or something; the old TIOCSSIZE "ioctl" didn't cause the signal to be sent, but the new TIOCSWINSZ "ioctl" does so in SunOS just as it does in BSD (and, I think, in System V Release 4).
eggert@twinsun.com (Paul Eggert) (06/27/91)
I wrote: >Sun even _removed_ from `vi' the autoresizing code that >they received from AT&T, because they couldn't fix its bugs! I got this story from a Sun maintenance engineer, but I've since been informed that it's a garbled version of reality. SunOS versions up through 4.0.x used Berkeley vi, which tries to handles window resize events although it mishandles some cases. Starting with version 4.1, SunOS uses System V vi, which has never handled window resizes. Because of this botch, many folks save 4.0.3 vi and reinstall it under the 4.1 OS. By the way, the Sun maintenance engineer was remarkably unapologetic about the bug, and indicated that it wouldn't get fixed any time soon, because he thought it would take too much of his time. Clearly an Emacs user (:-).
guy@auspex.auspex.com (Guy Harris) (06/28/91)
>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).