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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: tsdh@gnu.org,  acm@muc.de,  20404@debbugs.gnu.org
> Date: Thu, 23 Apr 2015 15:35:18 -0400
> 
> >> Hmm... while I guess it's still possible, it normally shouldn't happen:
> >> if the fontification takes place during the scrolling itself, then the
> >> next redisplay should not be skipped
> > How does this work?
> 
> The decision whether redisplay is skipped or not is based on the
> input-pending-p at the beginning of the command, i.e. before the call to
> move_it.
> So, if move_it triggers jit-lock which triggers font-lock, that means
> jit-lock found (during move_it) that input-pending-p was nil, which
> should imply that input-pending-p was also nil at the beginning of the
> command, and hence the next redisplay will not be skipped.

I'm not sure I see all this; perhaps I'm looking at the wrong places.

What I see is that the only reference to input-pending-p in
jit-lock.el is in jit-lock-function, where it is used to decide
whether to defer fontifications, which I believe is not what you were
describing above.

So how does "jit-lock find (during move_it) that input-pending-p is
nil"?