Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!ucbvax!NIC.GAC.EDU!scott
From: scott@NIC.GAC.EDU
Newsgroups: comp.emacs
Subject: vi triumphs over emacs! ("bug" in emacs)
Message-ID: <9009111909.AA00518@next-8.gac.edu>
Date: 11 Sep 90 19:09:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 34

Recently, I've gotten access to a NeXT (BSD) machine in my dorm room.  I've  
been using this for remote logins to our campus NeXT network.  This is pretty  
nice, but I almost always get snagged by the fact that window resize events  
are not propagated.

What happens is that I log into the system with a suitably large vt100 window,  
something like 80x72, and then eventually get into emacs to use gnus.  Fine.   
But, since almost without fail I forget to do my stty rows call first, I end  
up with only a small window out of this huge one.

So, what I attempt it ctrl-z out of emacs, stty rows 72, fg back in.  This  
doesn't fix it.  What I end up having to do is find the pid for emacs, and do:

(sleep 5 ; kill -WINCH <emacs-pid>) &
fg

after the stty, to get emacs to recognize the window size change.

Meanwhile, when doing various stuff at the command line, I tend to use vi  
(quicker, well, sort of).  In vi, I can ctrl-z out of the editting session,  
stty rows 72, and fg back in, without a problem.  vi detects the resize, and  
applies it.  Wonderful, none of this sleep/kill hoopla.

I guess I consider this a psuedo-bug.  Not really a bug, just something that  
was forgotted.  This same type of behaviour should also happen over telnet  
connections, and in very dumb terminal emulators.  But, luckly, I'm sure it's  
a quick and easy problem for any emacs guru to fix, I'm confident it will make  
its way into future versions of emacs.

Or is ours an old, slimey one?  Our version is 18.53.11, which is not the  
newest, but is certainly not all that old.

scott hess
scott@gac.edu