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

FWIW, when I set jit-lock-defer-time to zero and lean on the PageDown
key, I see somewhat clunky scrolling with no fontifications, until I
release the key.

But fontification inside the scrolling code itself still happens, I
think.