scott@NIC.GAC.EDU (09/12/90)
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
murthy@algron.cs.cornell.edu (Chet Murthy) (09/12/90)
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--
sdk@shadow.twinsun.com (Scott D Kalter) (09/12/90)
I'm not sure about the philosophy of all this but it seems to me you can probably just tell emacs what the window size is rather than suspending, running stty rows, and foregrounding emacs. To tell emacs to change its screensize just use: (set-screen-height <n>) Where <n> is the appropriate number of rows. Back to philosophy, If emacs were sent the SIGWINSZ automatically it seems all would be fine(?). I'm not sure I agree that emacs should be expected to go exploring for possible changes in the terminal structure everytime you foreground it. Anyway, I hope my work-around provides temporary relief. -sdk
ces@milton.u.washington.edu (Christopher e Stefan) (09/16/90)
hmm, sounds like you're using telnet instead of rlogin, it is generally a good idea when logging in from one Unix box to another to use rlogin instead of telnet (support for window size change, login without password w/properly set up .rhosts file, can be made to pass 8bits chars, etc.) -- Christopher e Stefan. | INTERNET: ces@u.washington.EDU | (206) 526-9817 "Natural causes, | UUCP: ... !beaver!blake!ces | 4746 21st Ave NE people just explode." | BITNET: ces%milton@UWAVM | Seattle WA, 98105
jbw@bucsf.bu.edu (Joseph Wells) (09/17/90)
>>>>> "Scott" == scott@NIC.GAC.EDU Scott> What happens is that I log into the system with a suitably large vt100 Scott> window, something like 80x72, and then eventually get into emacs to Scott> use gnus. Fine. But, since almost without fail I forget to do my Scott> stty rows call first, I end up with only a small window out of this Scott> huge one. Scott> So, what I attempt it ctrl-z out of emacs, stty rows 72, fg back in. Scott> This doesn't fix it. What I end up having to do is find the pid for Scott> emacs, and do: Scott> (sleep 5 ; kill -WINCH <emacs-pid>) & Scott> fg Scott> after the stty, to get emacs to recognize the window size change. The following piece of GNU Emacs Lisp should handle your problem: (setq emacs-pid (save-excursion (set-buffer (get-buffer-create " *Emacs PID*")) (erase-buffer) (call-process "/bin/sh" nil t nil "-c" "ps -l$$") (goto-char (point-min)) (let (case-fold-search) (re-search-forward "[ \t]+PID") (let ((col (current-column))) (forward-line 1) (move-to-column col)) (read (current-buffer))))) (setq suspend-resume-hook (function (lambda () (call-process "kill" nil nil nil "-lWINCH" (format "%s" emacs-pid))))) Scott> Meanwhile, when doing various stuff at the command line, I tend to use Scott> vi (quicker, well, sort of). In vi, I can ctrl-z out of the editting Scott> session, stty rows 72, and fg back in, without a problem. vi detects Scott> the resize, and applies it. Wonderful, none of this sleep/kill Scott> hoopla. GNU Emacs unfortunately only interrogates the system for the screen size when it receives a SIGWINCH and on startup. >>>>> "Chet" == murthy@algron.cs.cornell.edu (Chet Murthy) Chet> As I understood it, the _CORRECT_ protocol is for the Chet> terminal-emulator to signal the process group leader for the Chet> slave-side of the pseudo-terminal with WINCH, to let it know that the Chet> window size has changed. That is what SIGWINCH was invented for. That's exactly what's happening. His shell is the process group leader of the terminal's current process group. Chet> So the problem seems to me to be with NeXT's terminal emulator, not Chet> Emacs. Nope. Chet> But you're right - this is an easy problem to handle. Of course, if Chet> there were a way to get the process-id of Emacs easily (within Emacs), Chet> and do a UNIX kill(2), you could just do the kill from within Emacs. Chet> But apparently that has been left out. About 2 seconds' hacking. There is a way to get Emacs's pid without starting another process, if CLASH_DETECTION was specified when Emacs was built. Then you can lock a file and look at the contents of the lock file to get the pid. (Gross, huh?) -- Joe Wells <jbw@bu.edu>