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.