Re: input-pending-p

Re: input-pending-p

[Richard Stallman]

    I shall try to find out more; however, I am not very experienced at
    using gdb.  If you can give me some clues on how to proceed I shall
    see what I can find out.

Have you tried stopping Emacs using GDB when it is the "turn" for
the failure to happen, inserting a breakpoint at get_input_pending,
and stepping thru to see what happens?

If mouse motion gets in the way, it might help if you put the window
manager in click-to-focus mode and define keyboard commands to change
focus.  That way you could go to GDB without touching the mouse.

Other than that, I don't see how to give any more advice until you say
what obstacle you have encountered.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: input-pending-p

[David]

I have re-looked at this issue today with the following results.

* Problem Summary: input-pending-p yields an incorrect value 50% of the time
in emacs 21.1 and emacs-21.2 under some window managers.

* Result Summary: I have been unsuccessful in solving the problem.  I have
  made all the efforts that I can think of, with result that it appears that
  the problem lies in code called by get_input_pending in keyboard.c.  The
  problem only occurs when running under some window managers.  Truly simple
  demonstration code is not obvious.  The complex demonstration code is
  available to anyone; this complex code is simple to install and uninstall.

* My procedure was as follows.
  ** run under Gnome
  ** run one copy of emacs-21.1 as the testpiece
  ** run another emacs (which was emacs-21.2) running gdb, and attach the
     testpiece via its pid.
  ** do not use the mouse at all

* Following this procedure gives the sequence of outputs from input-pending-p
  as t t t t t ...

* Running the emacs-21.1 without gdb gives the sequence t nil t nil t ...

* The sequence from emacs-21.1 running under twm is nil nil nil nil nil ...
  and this is correct under the test conditions.

* The sequence from emacs-20.7 running under Gnome is nil nil nil nil nil ...
  and this is correct under the test conditions.

* Thus (my) using gdb modifies the problem so that I am unable to make
  comparisons.

* I put the following code into keyboard.c.  This gives entirely consistent
  results with what is seen in lisp.  I conclude that the problem lies in
  get_input_pending.

/* this function is used below */
void
FYS (str)
     char *str;
{
  Lisp_Object dummy;
  Lisp_Object * dumref;
  dummy = build_string (str);
  dumref = &dummy;
  Fmessage (1, dumref);
}

DEFUN ("input-pending-p", Finput_pending_p, Sinput_pending_p, 0, 0, 0,
  "T if command input is currently available with no waiting.\n\
Actually, the value is nil only if we can be sure that no input is available.")
  ()
{
  if (!NILP (Vunread_command_events) || unread_command_char != -1)
    return (Qt);

  get_input_pending (&input_pending, 1);
input_pending > 0 ? FYS("true") : FYS("false");
  return input_pending > 0 ? Qt : Qnil;
}

* It is possible to upset the t nil t nil t ... sequence by using "tricks", in
  particular by inputting two keystrokes in rapid succession
  ("double-clicking" on the keyboard).  But this leads me to no conclusion
  except to re-inforce the idea that the problem is a timing isue.  I think
  that interrupt_input always is 1, causing the return from get_input_pending,
  at least in the attached emacs-21.1 case.

static void
get_input_pending (addr, do_timers_now)
     int *addr;
     int do_timers_now;
{
  /* First of all, have we already counted some input?  */
  *addr = !NILP (Vquit_flag) || readable_events (do_timers_now);

  /* If input is being read as it arrives, and we have none, there is none.  */
  if (*addr > 0 || (interrupt_input && ! interrupts_deferred))
    return;

  /* Try to read some input and see how much we get.  */
  gobble_input (0);
  *addr = !NILP (Vquit_flag) || readable_events (do_timers_now);
}

* Also I again looked into producing a simple example; I do not see how to do
  that.  I can demonstrate, what really is deducible anyway, that the problem
  only occurs when I involve X: I have a toggle on the code that uses either
  popup frames or windows in the parent emacs; the latter continues to work
  perfectly.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: input-pending-p

[Eli Zaretskii]

On Sun, 24 Mar 2002, David wrote:

> I have re-looked at this issue today with the following results.
> 
> * Problem Summary: input-pending-p yields an incorrect value 50% of the time
> in emacs 21.1 and emacs-21.2 under some window managers.

Is that in "emacs -q --no-site-file"?  If not, there could be all kinds 
of optional features that generate input events.  Even without optional 
features, there could be X events delivered to Emacs behind your back (the 
dependence on window manager seems to indicate that this really happens).

I'd suggest to look at the event queue and see what kinds of events are 
there.  That would make debugging this a whole lot easier, and the 
discussion much more focused.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: input-pending-p

[Richard Stallman]

I am not surprised that you did not learn anything because your
method was to observe the function from the outside only.
That method is so ineffective that I recommend never trying it.

To figure out what happens inside get_input_pending, you have to
investigate it from the inside.  If you save data recorded at various
points within the function, you might learn something useful.  Try to
find out what kind of input events are in the queue or passed through
the queue.  Try to find out what sort of X events were read in, and
where control passed in the handling of them.  That is a sure and
steady method to get to the bottom of things.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: input-pending-p

[David]

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.

So far this patch has solved the problem for me.

patch for 21.2 keyboard.c

6245,6250c6245,6253
<       kbd_buffer_store_event (&buf[i]);
<       /* Don't look at input that follows a C-g too closely.
< 	 This reduces lossage due to autorepeat on C-g.  */
<       if (buf[i].kind == ascii_keystroke
< 	  && buf[i].code == quit_char)
< 	break;
---
>       if (buf[i].kind != FOCUS_IN_EVENT)
>         {
>           kbd_buffer_store_event (&buf[i]);
>           /* Don't look at input that follows a C-g too closely.
>              This reduces lossage due to autorepeat on C-g.  */
>           if (buf[i].kind == ascii_keystroke
>               && buf[i].code == quit_char)
>             break;
>         }

dajo

>  - 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.

Re: input-pending-p

[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
> 
> 

Re: input-pending-p

[David]

Hello Kim,

Thank you for your suggestion.  Unfortunately it does not solve the
problem.  RMS has sent me a patch for keyboard.c alternative to mine
which appears to work.  I assume that you can access this patch via
some fsf-internal mechanism.

dajo


> 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