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

[Stefan Monnier]

>> What was it?  That input-pending-p returns nil even though there are
>> lots of pending events (because they haven't been processed enough for
>> Emacs to realize they're there)?  Could you make a bug report about this
>> issue, describing under which circumstances this happens?  Or do we have
>> one already?
> Maybe we are not talking about the same thing.  I meant these
> messages:
>   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).
If that's the case, we should have a bug report about that.

>   http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg01039.html
>   http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg01055.html

These talk about something else, which is partly outdated.

> I don't see the special case of zero discussed back there, so perhaps
> this is a different problem.

That's because the code has changed since.  Now redisplay (which happens
after running a command) is skipped based on the value of
`input-pending-p' at the beginning of the *command*, rather than based
on its value at the beginning of redisplay.  And jit-lock.el has been
changed to use (not (input-pending-p)), but only if jit-lock-defer-time
is 0, so the special case for 0 is new.


        Stefan