🚀 go-pugleaf

Well since I saw my followup message but not the original one with the
patch, I'm going to go ahead and repost.  As an aside, why did my
other message, which I'd sent to bug-gnu-emacs-request get forwarded
to the whole list?  Shouldn't that have just gone to the
moderator/administrator of the list?  Ah well, maybe this message will
improve my signal-to-noise ratings :-)...

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	Wed Mar 27 14:29:45 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,1398 ----
        break;
  
+ 		/* focus logic rewritten  8-Mar-1991 bwarsaw@cen.com */
      case FocusIn:
      case FocusOut:
!     case EnterNotify:
      case LeaveNotify:
! 		{
! 		Window focus;
! 		int revert_to;			/* dummy return val */
! 		int cursor = -1;		/* 0=on, 1=off, -1=no change */
! 		XGetInputFocus( XXdisplay, &focus, &revert_to );
! 
! 		if( event.type == FocusIn ) cursor = 0;
! 		else if( event.type == FocusOut ) cursor = 1;
! 		else if( focus == PointerRoot )
! 			cursor = (event.type == LeaveNotify) ? 1 : 0;
! 
! 		if( cursor == -1 ) break;
! 		CursorToggle();
! 		CursorOutline = cursor;
! 		CursorToggle();
! 		}
        break;