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: Thu, 23 Apr 2015 22:52:08 +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:31:56 -0400
> 
> > I don't see how what you say can follow from what I wrote in that message.
> 
> I just misunderstood.
> 
> > But that doesn't mean input-pending-p will return nil when there's
> > input unread by read_socket_hook, because once our keyboard queue gets
> > emptied, readable_events will return zero, and then we _will_ call
> > read_socket_hook to fill our queue, and then the second call to
> > readable_events will return non-zero, and input-pending-p will return
> > non-nil.
> 
> Good.  But then I don't understand why Tassilo gets the same display
> freezes with jit-lock-defer-time set to 0 as when jit-lock-defer-time is
> set to nil.

Neither do I.  I see a very big difference: with jit-lock-defer-time
set to zero, the freezes are minor and almost non-existent.  With it
set to nil, they are much more evident and much longer.

> You seem to say that you know why (and that you explained it in those
> old discussions), but I guess I don't understand those explanations.

I never said the value of zero should have no effect, nor do I thing
it should, or does.

Previous Next

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