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

Previous Next

Package: emacs;

Reported by: Tassilo Horn <tsdh <at> gnu.org>

Date: Wed, 22 Apr 2015 09:47:01 UTC

Severity: normal

Tags: moreinfo

Found in version 25.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #77 received at 20404 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#20404: 25.0.50;
 Sometimes no fontification with jit-lock-defer-time
Date: Thu, 23 Apr 2015 20:03:11 +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 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.




This bug report was last modified 5 years and 282 days ago.

Previous Next


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