Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!cornell!murthy
From: murthy@algron.cs.cornell.edu (Chet Murthy)
Newsgroups: comp.emacs
Subject: Re: vi triumphs over emacs! ("bug" in emacs)
Message-ID: <45656@cornell.UUCP>
Date: 11 Sep 90 20:08:37 GMT
References: <9009111909.AA00518@next-8.gac.edu>
Sender: nobody@cornell.UUCP
Organization: Cornell Univ. CS Dept. Ithaca NY
Lines: 38

scott@NIC.GAC.EDU writes:

>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.

As I understood it, the _CORRECT_ protocol is for the
terminal-emulator to signal the process group leader for the
slave-side of the pseudo-terminal with WINCH, to let it know that the
window size has changed.  That is what SIGWINCH was invented for.
So the problem seems to me to be with NeXT's terminal emulator, not
Emacs.

But you're right - this is an easy problem to handle.  Of course, if
there were a way to get the process-id of Emacs easily (within Emacs),
and do a UNIX kill(2), you could just do the kill from within Emacs.
But apparently that has been left out.  About 2 seconds' hacking.

--chet--