Article View: gnu.emacs.bug
Article #98623Re: X Focus problem, vers 18.57
From: Barry A. Warsaw
Date: Mon, 13 May 1991 12:57
Date: Mon, 13 May 1991 12:57
119 lines
4973 bytes
4973 bytes
RMS tells me that I may have goofed and posted my patch instead of
mailing it. And I should know better! So here's an re-send with the
correct patch included. Apologies for duplications. Hopefully, I can
shut up now ;-)
I should note that the patch below is the second of two that I posted.
This one contains basically the same logic as the first, but removes
two Xtraneous round-trips to the X server (XGetInputFocus), when the
returned information wasn't being used.
--------------------begin included message--------------------
Anyway, someone posted a message saying that when running under X, the
emacs block cursor will occasionally not correctly change from hollow
to solid when it gets keyboard focus. Sorry, I don't have the
original article on-line anymore. I run X11R4.18 MIT XSun server on a
SS1+ with SunOS 4.1.1. I use twm and emacs 18.57 and noticed this
problem when emacs 18.57 came out.
The reason this happens is that emacs takes a simplified approach to
determining when it has keyboard focus and when it doesn't.
Unfortunately, determining whether you have focus or not is more
complicated and for that reason emacs sometimes gets confused.
Compare this with xterm which rarely (if ever -- I've never seen it)
gets confused.
So I did some hacking on x11term.c and patched it such that it seems
to correct the problem -- at least in all situations that I've tried.
In any event, I've been running my patched emacs for a couple of
months now and it seems to be working great; the focus problem has
gone away and I haven't noticed any new bugs introduced by my patch.
One note though: I ran this patch past some Xperts and it was pointed
out that using XGetInputFocus can introduce a TEMPORARY race condition
if focus changes rapidly between the notification and before the call
to XGetInputFocus, returning the wrong window. However, this is
guaranteed to resolve correctly since emacs will always be informed of
all focus changes and will eventually sync with its XGetInputFocus.
In practice, I've never seen even a small delay when focusing into or
out of emacs (of course, this is on a SS1+, so...), let alone any hint
of entering an infinite loop.
I'd hoped to get more time to work on the focus problem, to explore a
different approach, but I just don't have the time, so I'm posting
this for those who need a fix now, and so others can improve on it.
Maybe v19 will do focus correct; I haven't looked at how epoch does
it. The patch to x11term.c follows my signature.
-Barry
NAME: Barry A. Warsaw INET: warsaw@nlm.nih.gov
TELE: (301) 496-1936 UUCP: uunet!nlm.nih.gov!warsaw
--------------------cut here--------------------
*** x11term.c.orig Wed Mar 6 13:45:49 1991
--- x11term.c Fri May 10 15:08:44 1991
***************
*** 161,167 ****
int XXfontw, XXfonth, XXbase, XXisColor;
- /* Nonzero means Emacs has explicit keyboard focus. */
- int x_focus_flag;
-
Colormap XXColorMap;
char *default_window;
--- 161,164 ----
***************
*** 1377,1400 ****
break;
case FocusIn:
- x_focus_flag = 1;
- case EnterNotify:
- if (event.type == FocusIn || (!x_focus_flag && event.xcrossing.focus))
- {
- CursorToggle ();
- CursorOutline = 0;
- CursorToggle ();
- }
- break;
-
case FocusOut:
! x_focus_flag = 0;
case LeaveNotify:
! if (event.type == FocusOut || (!x_focus_flag && event.xcrossing.focus))
! {
! CursorToggle ();
! CursorOutline = 1;
! CursorToggle ();
! }
break;
--- 1374,1399 ----
break;
+ /* focus logic rewritten 8-Mar-1991 bwarsaw@cen.com */
case FocusIn:
case FocusOut:
! case EnterNotify:
case LeaveNotify:
! {
! int cursor = -1; /* 0=on, 1=off, -1=no change */
!
! if( event.type == FocusIn ) cursor = 0;
! else if( event.type == FocusOut ) cursor = 1;
! else {
! Window focus;
! int revert_to; /* dummy return val */
! XGetInputFocus( XXdisplay, &focus, &revert_to );
! if( focus == PointerRoot )
! cursor = (event.type == LeaveNotify) ? 1 : 0;
! }
! if( cursor == -1 ) break;
! CursorToggle();
! CursorOutline = cursor;
! CursorToggle();
! }
break;
Technical Details
Message-ID:
<9105131257.AA04427@warsaw.nlm.nih.gov>Path:
arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!tut.cis.ohio-state.edu!unreplyable!garbageShow Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fb2f1,97c483d3c6be16cf,start X-Google-Attributes: gidfb2f1,public X-Google-ArrivalTime: 1991-05-13 05:57:45 PST Path: arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!tut.cis.ohio-state.edu!unreplyable!garbage From: warsaw@NCBI.NLM.NIH.GOV (Barry A. Warsaw) Newsgroups: gnu.emacs.bug Subject: Re: X Focus problem, vers 18.57 Message-ID: <9105131257.AA04427@warsaw.nlm.nih.gov> Date: 13 May 91 12:57:45 GMT Sender: daemon@tut.cis.ohio-state.edu Reply-To: warsaw@ncbi.nlm.nih.gov Distribution: gnu Organization: GNUs Not Usenet Lines: 119 Approved: bug-gnu-emacs@prep.ai.mit.edu