Moving discussion from xemacs-patches to xemacs-beta. ms> It looks OK to me, but since you seem to be knowledgeable in ms> things X, I would be interested in a diagnosis on why the old ms> code failed. It does look like a bug in Xt, doesn't it? What's happening here is that people are assuming session management and logging out from xdm/gdm/whatever, without shutting down XEmacs. That's the situation that generates the symptom (lingering XEmacs process consuming 100% CPU). gdm, as you would expect[1], takes all the care of a Microsoft operating system in shutting down. Anyway, XEmacs loses its last X device and goes into a spin in that CONSOLE_DEVICE_LOOP. A real session manager would shut down XEmacs (the user has logged out of the session that XEmacs was started in, and XEmacs is a foreground app there). xdm and xsm both do this. I believe (but haven't checked) that the patch "works" because after finding no connections the code falls through to a place where XEmacs realizes it has no live consoles and exits. I don't consider it a bug in Xt; note that XtAppPending is a building block for event loops, not an event loop, so I think it's our responsibility to check for live dpys. (I hate it, but the "caller provides correct input or I crash" policy is consistent throughout X11.) I think in the long run what we want to do is make XEmacs a server process, with display clients. (Isn't it your comment that "maybe we can finally move the first frame into startup.el"? Whoever wrote that inspired this wacky idea.) Footnotes: [1] At least I have come to. I will _not_ use GTK/GNOME software anywhere near security or system management functions, and I'm nervous about the results produced by Gnumeric ;-) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py