GNU bug report logs - #20404
25.0.50; Sometimes no fontification with jit-lock-defer-time

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: acm <at> muc.de, 20404 <at> debbugs.gnu.org, tsdh <at> gnu.org
Subject: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time
Date: Fri, 24 Apr 2015 12:41:16 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: tsdh <at> gnu.org,  acm <at> muc.de,  20404 <at> 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"?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.