sridhar@consl5.esg.dec.com (Pete Sridharan) (11/08/90)
I am running Openlook 2.0 of AT&T on 386 running SVR 3.2.2:
Is there a way of setting resources so that xterms that are running
screen
oriented programs like vi and (vannila) emacs can be resized. It
doesn't seem to
allow window resizing for those programs.
Thanks in advance for your help.
/***********************************************************************
*********/
/* Pete Sridharan sridhar%consl5.esg.dec.com@decwrl.dec.com */
/* Digital Equipment Corporation, Four Results Way, Marlboro, MA 01752 */
/* (WORK) 508-467-6684 (HOME) 508-653-7208
*/
/***********************************************************************
*********/kucharsk@number6.Solbourne.COM (William Kucharski) (11/09/90)
In article <3391@ryn.esg.dec.com> sridhar@consl5.esg.dec.com (Pete Sridharan) writes: > I am running Openlook 2.0 of AT&T on 386 running SVR 3.2.2: > > Is there a way of setting resources so that xterms that are running screen > oriented programs like vi and (vannila) emacs can be resized. It > doesn't seem to allow window resizing for those programs. AT&T's xterm implementation understands a "magic cookie" sequence which tells the xterm to not allow resizing; this is what is happening here. This is to avoid the nasty consequences of the fact that SVR3 doesn't have a SIGWINCH signal to inform other processes of window size changes, and that SVR3 vi(1) obviously wouldn't understand it even if it did. Yes, things change in SVR4... -- ===================>> Quote: "It's Night 9 With D2 Dave!" <<=================== | Internet: kucharsk@Solbourne.COM | William Kucharski | | uucp: ...!{boulder,sun,uunet}!stan!kucharsk | Solbourne Computer, Inc. | ===>> Opinions expressed above are MINE, not those of Solbourne Computer. <<===
robbie@tivoli.UUCP (robbie) (11/09/90)
In article <3391@ryn.esg.dec.com> sridhar@consl5.esg.dec.com (Pete Sridharan) writes: > > I am running Openlook 2.0 of AT&T on 386 running SVR 3.2.2: > > Is there a way of setting resources so that xterms that are running screen > oriented programs like vi and (vannila) emacs can be resized. It doesn't seem to > allow window resizing for those programs. > > Thanks in advance for your help. Nope, not unless you have source for emacs or vi. I worked at IBM on AIX and fixed my own versions to deal with this properly. I tried to get into the product but they wouldn't let me. The only system I have seen that deals with this properly is Ultrix. If you want to fix the code you can do it easily. Just trap SIGWINCH(you ignore it by default), do an ioctl() on your pty to get the new size (xterm should blat this info into the pty whenever the size is changed), and then have the program do a re-init on curses for vi, or i-don't-know-what for emacs with the new size. Other than that you are SOL. You're lucky it works on anything but 24x80. Try Interactive 386ix for instance. I only got it to work because I had fixed bugs in the IBM version of the source, and knew that ISC was the same source base at one point in time. sorry and good luck, Robbie Robinette 512 329 2455
patl@Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.]) (11/09/90)
|> In article <3391@ryn.esg.dec.com> sridhar@consl5.esg.dec.com (Pete Sridharan) writes: |> > |> > I am running Openlook 2.0 of AT&T on 386 running SVR 3.2.2: |> > |> > Is there a way of setting resources so that xterms that are running screen |> > oriented programs like vi and (vannila) emacs can be resized. It doesn't seem to |> > allow window resizing for those programs. |> > |> > Thanks in advance for your help. |> |> Nope, not unless you have source for emacs or vi. I worked at IBM on |> AIX and fixed my own versions to deal with this properly. I tried to |> get into the product but they wouldn't let me. The only system I have |> seen that deals with this properly is Ultrix. If you want to fix the |> code you can do it easily. Just trap SIGWINCH(you ignore it by |> default), do an ioctl() on your pty to get the new size (xterm should |> blat this info into the pty whenever the size is changed), and then |> have the program do a re-init on curses for vi, or i-don't-know-what |> for emacs with the new size. Other than that you are SOL. GNU emacs (18.54) catches SIGWINCH and resizes properly under SunOS.
eggert@twinsun.com (Paul Eggert) (11/10/90)
Under SunOS 4.1, vi _still_ doesn't respond to SIGWINCH, no matter what the windowing system. If you resize a window containing a vi session, your screen will turn to garbage. I have reported this bug to Sun several times, starting five years ago, but Sun has never fixed it. GNU Emacs gets this right. vi on most other vendors' Unix workstations get this right -- I just tested it on DEC, Omron, SGI, and Sony. But vi on a Sun workstation is still broken. Ironic, isn't it, given that vi's author is Sun's R&D VP? I guess Bill Joy really does use Emacs.
guy@auspex.auspex.com (Guy Harris) (11/11/90)
>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.
eggert@twinsun.com (Paul Eggert) (11/11/90)
guy@auspex.auspex.com (Guy Harris) writes: >1) if you resize the window, "vi" will resize its display, *even when > you're in insert mode*? No, DEC et al. get this wrong, because they just copied 4.3BSD behavior. This is better than Sun's disabling of SIGWINCH handling, because at least window resizing works much of the time; but you're right, it's still buggy.