jeff1@garfield.mun.edu (Jeff Sparkes) (10/15/88)
Emacs 18.52 doesn't work properly under X11 on Ultrix 2.0. When I start up emacs from an xterm, it doesn't receive input properly. I can type into the emacs window, but it doesn't get any input until I hit return in the xterm window that I started emacs in. It seems to be still trying to get input from the original window. -- Jeff Sparkes jeff1@garfield.mun.edu .and the cows burned on into the night. -Tom Wolfe, The Right Stuff
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (10/17/88)
In article <4933@garfield.MUN.EDU> jeff1@garfield.mun.edu (Jeff Sparkes) writes: > Emacs 18.52 doesn't work properly under X11 on Ultrix 2.0. Are you using the patches from the emacs-11@bloom-beacon.mit.edu mailing list (also available via FTP from tut.cis.ohio-state.edu or via UUCP from osu-cis)? -=- Zippy sez, --Bob JAPAN is a WONDERFUL planet -- I wonder if we'll ever reach their level of COMPARATIVE SHOPPING...
schoett@lan.informatik.tu-muenchen.dbp.de (Oliver Schoett) (10/18/88)
In article <4933@garfield.MUN.EDU> jeff1@garfield.mun.edu (Jeff Sparkes) writes: > Emacs 18.52 doesn't work properly under X11 on Ultrix 2.0. When I > start up emacs from an xterm, it doesn't receive input properly. I > can type into the emacs window, but it doesn't get any input until I > hit return in the xterm window that I started emacs in. It seems to > be still trying to get input from the original window. I've observed this bug with GNU Emacs 18.51 and 18.52 under Ultrix 2.2 and X11R2. It happens when the DISPLAY environment variable is set to "unix:0" (indicating a "Unix domain" connection) and goes away when DISPLAY is set to "hostname:0" (hostname=name of your or any other machine, indicating a TCP/IP connection). I've circumvented the bug with a little shell script wrapped around emacs that resets the DISPLAY variable when it is "unix:0", but I'd like to have a real fix to the problem, too. Oliver Schoett Inst. f\"ur Informatik, Technische Univ. M\"unchen, Postfach 20 24 20, 8000 M\"unchen 2, West Germany schoett@lan.informatik.tu-muenchen.dbp.de +49 89 2105 2390 schoett%lan.informatik.tu-muenchen.dbp.de@ {relay.cs.net, unido.uucp}
jeff1@garfield.mun.edu (Jeff Sparkes) (10/18/88)
In article <24782@tut.cis.ohio-state.edu>, bob@allosaur (Bob Sutterfield) writes: >In article <4933@garfield.MUN.EDU> jeff1@garfield.mun.edu (Jeff Sparkes) writes: >> Emacs 18.52 doesn't work properly under X11 on Ultrix 2.0. > >Are you using the patches from the emacs-11@bloom-beacon.mit.edu >mailing list (also available via FTP from tut.cis.ohio-state.edu or >via UUCP from osu-cis)? No, I'm not. Would it be possible to post them? UUCP access is impossible, and ftp has to go through an intermediary. Also, several people have asked me to pass on any information that I received, so it seems like I'm not the only one who needs this. -- -- Jeff Sparkes jeff1@garfield.mun.edu .and the cows burned on into the night. -Tom Wolfe, The Right Stuff
schoett@lan.informatik.tu-muenchen.dbp.de (Oliver Schoett) (10/24/88)
In article <24782@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: > In article <4933@garfield.MUN.EDU> jeff1@garfield.mun.edu (Jeff > Sparkes) writes: > > > Emacs 18.52 doesn't work properly under X11 on Ultrix 2.0. > > Are you using the patches from the emacs-11@bloom-beacon.mit.edu > mailing list (also available via FTP from tut.cis.ohio-state.edu or > via UUCP from osu-cis)? I FTPed the patches in pub/gnu/emacs/18.52-X11R2.Z from tut.cis.ohio-state.edu and installed them. The bug is still there: when DISPLAY is unix:0, emacs doesn't get its input until return is typed to it in the calling shell window (when emacs is run as 'emacs &', it doesn't get its input at all; when DISPLAY is hostname:0, emacs works fine). I'm using GNU Emacs 18.52 under Ultrix 2.2 with the X11R2 Xqvss server on a monochrome VaxStation II/RC. Oliver Schoett Inst. f\"ur Informatik, Technische Univ. M\"unchen, Postfach 20 24 20, 8000 M\"unchen 2, West Germany schoett@lan.informatik.tu-muenchen.dbp.de +49 89 2105 2390 schoett%lan.informatik.tu-muenchen.dbp.de@ {relay.cs.net, unido.uucp}
cks@white.toronto.edu (Chris Siebenmann) (10/26/88)
In article <358@infovax.lan.informatik.tu-muenchen.dbp.de> schoett@lan.informatik.tu-muenchen.dbp.de (Oliver Schoett) writes: .. >I've observed this bug with GNU Emacs 18.51 and 18.52 under Ultrix 2.2 >and X11R2. It happens when the DISPLAY environment variable is set to >"unix:0" (indicating a "Unix domain" connection) and goes away when >DISPLAY is set to "hostname:0" (hostname=name of your or any other >machine, indicating a TCP/IP connection). We had exactly the same problem running Emacs 18.51 under Ultrix 2.2 and X11R2. I counldn't find a consistent spot where it hung; checking in the debugger seemed to show it spinning around deep in the internals of the input code and the X11 input code. After reading a comment on the Emacs-under-X11 mailing list I tried rebuilding Emacs with s-bsd4-3.h instead of s-bsd4-2.h, and that got rid of the problem. I suspect from some comments on the Emacs-under-X11 mailing list that it may be a problem with the INTERRUPT_INPUT define, but I've never been gung-ho enough to try and find out. -- "I shall clasp my hands together and bow to the corners of the world." Number Ten Ox, "Bridge of Birds" Chris Siebenmann ...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks cks@white.toronto.edu or ...!utgpu!{,csri!}cks
janssen@titan.sw.mcc.com (Bill Janssen) (10/28/88)
I had a problem that may or may not be similar with a branch variant of GNU Emacs we run here, under X. Every so often it would go into a very compute-intensive loop, but not doing anything to the X-window it was running in. We tracked this down to a bug in the "fcntl" code for sockets, in that only the group leader of the process group received SIGIO's, though the code *apparently* sets up the groups so that all members of the group will receive SIGIO. The emacs code under X basically sits in a select statement, waiting for input to be delivered from the X server or from some dependent process. When input comes in from the X server, it expects to see that a SIGIO has happened before the select has returned. When the select returns, Emacs checks a flag to see if a SIGIO has been delivered. If it has, it goes to read the X socket. If not, it goes back into its select. Under some conditions, Emacs is not the group leader of its process group, and never receives SIGIO. If you are running with INTERRUPT_INPUT, it will continue to bounce out of and back into that select statement forever. A quick fix is to slap a "setpgrp" statement in somewhere, so that Emacs is always the process leader of its process group. Another fix, and I thought this was already in the 18.51 code, was to check the input a bit differently when coming out of the select statement. Bill