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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 24 Apr 2015 12:41:16 +0300

> From: Stefan Monnier <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> 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"?