Charles Waldman writes:
I'm using VM version 8.0.12-devo-585 in xemacs-21.5.32. I have
single vm-spool-file set up, which is an imap server. When I am
retrieving a large number of messages (for example, coming back
from vacation) I am unable to do anything else for a long period of
time, since XEmacs is insisting on keeping keyboard focus. I can
click on other windows (e.g. web browser) and they respond, but
it's impossible to *type* into any other window until VM is done
retrieving the messages. Is there any way to change this behavior?
AFAIK, the only thing that can have that effect that is under control
of a client is a call to XGrabKeyboard. There's exactly one such call
in XEmacs 21.5 I could find, in x-grab-keyboard. There are no calls
to x-grab-keyboard in XEmacs sources that I found.
XEmacs does set focus on itself in response to events, of course, but
that doesn't prevent other windows from focusing on themselves. And I
can't imagine why XEmacs would be tightly looping on XSetInputFocus at
the same time that it's blocked on I/O. You could try checking if
XEmacs is receiving any FocusIn events with xev, I guess, or if the
window you click in is geting FocusIn and FocusOut events while XEmacs
is blocked on I/O.
OTOH, I have experienced input issues like that with broken window
managers, in particular with quartz-wm on the Mac. Of course XEmacs
is always running so I can't be sure it's *not* XEmacs :-), but I've
never experienced an effect like the one you're talking about. On the
Mac, hiding and then unhiding X11 seems to restore console I/O to the
X server. Have you tried minimizing XEmacs while it's retrieving
messages? How about minimizing and unminimizing the window you want
to receive focus?
XEmacs-Beta mailing list