Re: input-pending-p

[storm@cua.dk (Kim F. Storm)]

David <dajo@Rednose.Rhubarb> writes:

> I think that I have found out the cause of this problem.  I *have*
> found out how to solve the problem from my point of view.  Currently I
> am testing to the extent possible.  Please be aware that I do not have
> a comfortable grasp of what is happening in Emacs; what I write and
> what I have done is inspired guesswork.
> 
> If you have any commentary I shall be pleased to receive it.  I am
> especially interested in knowing if this problem will be addressed in
> future releases.
> 
> It seems that Gnome/sawfish is fond of generating FOCUS_IN_EVENT
> events (and other stuff - Emacs gets quite busy).  These events then
> are put into the Emacs event queue and result in a positive yield from
> input-pending-p when really there is nothing there.  The problem does
> not arise with fvwm, twm, etc because they do not generate the
> FOCUS_IN_EVENT events.

Hi David,

From your analysis, it does indeed seem like excessive FocusIn events
are confusing emacs.  However, your patch is a bit radical (as it
effectively ignores those events).

Please try the following patch to see if it solves the problem.  This
is from the latest CVS version, but should apply directly to 21.2.
Remember to undo your own patch before testing.

Index: xterm.c
===================================================================
RCS file: /cvs/emacs/src/xterm.c,v
retrieving revision 1.735
diff -c -r1.735 xterm.c
*** xterm.c	28 May 2002 20:27:59 -0000	1.735
--- xterm.c	5 Jun 2002 20:53:20 -0000
***************
*** 10784,10790 ****
  	      f = x_any_window_to_frame (dpyinfo, event.xfocus.window);
  	      if (event.xfocus.detail != NotifyPointer)
  		dpyinfo->x_focus_event_frame = f;
! 	      if (f)
  		{
  		  x_new_focus_frame (dpyinfo, f);
  
--- 10784,10790 ----
  	      f = x_any_window_to_frame (dpyinfo, event.xfocus.window);
  	      if (event.xfocus.detail != NotifyPointer)
  		dpyinfo->x_focus_event_frame = f;
! 	      if (f && f != dpyinfo->x_focus_frame)
  		{
  		  x_new_focus_frame (dpyinfo, f);
  
++kfs


> 
> >  - Function: input-pending-p
> >      This function determines whether any command input is currently
> >      available to be read.  It returns immediately, with value `t' if
> >      there is available input, `nil' otherwise.  On rare occasions it
> >      may return `t' when no input is available.
> > 
> > You might like to know that this function is, newly, giving me trouble
> > so that the "rare occasions" occur exactly 50% of the time.  I am
> > calling the function in small (1-5) bursts and the value yielded by
> > input-pending-p is predictably and reliably nil on the odd-numbered
> > calls and t on the even numbered calls.  Under the conditions that
> > pertain the value always should be nil.
> > 
> > The code that, now, is failing is years old, has been in use
> > sucessfully for years, and, what is interesting, now performs like
> > this.
> > 
> > Emacs 20.7, window managers twm, fvwm, Gnome:  works properly
> > Emacs 21.1, window managers twm, fvwm:         works properly
> > Emacs 21.1, window managers Gnome, KDE:        fails as indicated
> > It is difficult for me to check KDE and 20.7 at the moment.
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> 
>