bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: tsdh@gnu.org,  acm@muc.de,  20404@debbugs.gnu.org
> Date: Thu, 23 Apr 2015 12:23:02 -0400
> 
> >   http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00705.html
> 
> This message of yours seems to be talking about the problem I'm
> referring to above.  At least, the way I read it, it seems to say that
> `input-pending-p' can return nil even if there is pending input
> (because that pending input is still in the system's input queue).

I don't see how what you say can follow from what I wrote in that
message.  What I say there is that while we process keystrokes, we
don't call read_socket_hook.  This observation is based on the code of
get_input_pending, which is the workhorse of input-pending-p:

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

   /* If input is being read as it arrives, and we have none, there is none.  */
   if (!input_pending && (!interrupt_input || interrupts_deferred))
     {
       /* Try to read some input and see how much we get.  */
       gobble_input ();
       input_pending = (!NILP (Vquit_flag) || readable_events (flags));
     }

   return input_pending;

The call to read_socket_hook is in gobble_input, so if the first call
to readable_events returns non-zero, as it happens when we have events
waiting in our keyboard queue, we won't call read_socket_hook.

But that doesn't mean input-pending-p will return nil when there's
input unread by read_socket_hook, because once our keyboard queue gets
emptied, readable_events will return zero, and then we _will_ call
read_socket_hook to fill our queue, and then the second call to
readable_events will return non-zero, and input-pending-p will return
non-nil.