procyberian/emacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

(XTread_socket) <ClientMessage, WM_TAKE_FOCUS>:

Browse source 
Don't call XSetInputFocus because that can generate additional
FocusIn events.
This commit is contained in:
Gerd Moellmann 1999-10-08 11:33:09 +00:00
parent 58af228738
commit f1da8f069e
2 changed files with 20 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
src/ChangeLog
View file

@ -1,3 +1,9 @@
1999-10-08 Gerd Moellmann <gerd@gnu.org>
* xterm.c (XTread_socket) <ClientMessage, WM_TAKE_FOCUS>:
Don't call XSetInputFocus because that can generate additional
FocusIn events.
1999-10-07 Jeffrey C Honig <jch@bsdi.com>
* bsdos4.h [HAVE_LIBNCURSES]: Define TERMINFO and LIBS_TERMCAP.

14
src/xterm.c
View file

@ -8723,6 +8723,19 @@ XTread_socket (sd, bufp, numchars, expected)
if (f && FRAME_XIC (f))
XSetICFocus (FRAME_XIC (f));
#endif
#if 0 /* Emacs sets WM hints whose `input' field is `true'. This
instructs the WM to set the input focus automatically for
Emacs with a call to XSetInputFocus. Setting WM_TAKE_FOCUS
tells the WM to send us a ClientMessage WM_TAKE_FOCUS after
it has set the focus. So, XSetInputFocus below is not
needed.
The call to XSetInputFocus below has also caused trouble. In
cases where the XSetInputFocus done by the WM and the one
below are temporally close (on a fast machine), the call
below can generate additional FocusIn events which confuse
Emacs. */
/* Since we set WM_TAKE_FOCUS, we must call
XSetInputFocus explicitly. But not if f is null,
since that might be an event for a deleted frame. */
@ -8743,6 +8756,7 @@ XTread_socket (sd, bufp, numchars, expected)
x_uncatch_errors (d, count);
}
/* Not certain about handling scroll bars here */
#endif /* 0 */
}
else if (event.xclient.data.l[0]
== dpyinfo->Xatom_wm_save_yourself)