GNU bug report logs - #12937
24.2; Fontification performed in 'jit-lock-defer-time' in any case (don't wait while Emacs become really idle).

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Oleksandr Gavenko <gavenkoa <at> gmail.com>
Cc: 12937 <at> debbugs.gnu.org
Subject: Re: bug#12937: 24.2; Fontification performed in 'jit-lock-defer-time'
	in any case (don't wait while Emacs become really idle).
Date: Mon, 19 Nov 2012 16:29:02 -0500

> I would try to workaround jerks with:
>   (setq jit-lock-defer-time 0.01)
> and with same negative effect by (see below):
>   (setq jit-lock-defer-time 3.0)

I don't see that.  I'm not sure how you tried, it but I did

  src/emacs -Q --eval '(setq jit-lock-defer-time 0.01)' src/xdisp.c

and scrolling with page-down indeed is jerky and I see that the buffer
is getting fontified (at least occasionally).  But if I try again with

  src/emacs -Q --eval '(setq jit-lock-defer-time 0.1)' src/xdisp.c

then the scrolling is fast&smooth and it only gets fontified when
I stop scrolling.

I suspect that fontification takes place in the 0.01s case because
redisplay itself takes more than 0.01s, so after redisplay we check
timers and see that we've been idle for more than 0.01s (and there's no
input yet because my repeat rate is 30Hz).

BTW, with 0.01s the behavior is particularly poor because the redisplay
is even slower than without it: we first do a redisplay without
fontification, and then we fontify and have to redo a redisplay, so the
first redisplay is mostly wasted work.

> Also note that fixing CC-mode is not a solution as there are many possible
> external modes that can be useful but with slow fontification.

Fixing cc-mode is not a general solution, indeed, but it should also be done.


        Stefan

Previous Next

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