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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Wed, Apr 22, 2015 at 01:37:13PM -0400, Stefan Monnier wrote:
> [ OFFTOPIC: the bug report is not about performance but about
>   a functional bug in jit-lock-defer.  ]

> > There's a solution (or, depending on your point of view, a workaround)
> > for this.  You're using Emacs-25, so set fast-but-imprecise-scrolling to
> > t, or customize it (it's in customisation group "scrolling").

> FWIW, on my machine, this doesn't make much difference: a single
> "font-lock one screen's worth" takes much too long, so after that one
> screen is displayed, Emacs takes a while catching up (with no display at
> all in the mean time).

How long is "too long"?  Do you mean that, with
fast-but-imprecise-scrolling non-nil, jit-lock-defer-time nil, holding
down C-v, that there is no redisplay for several seconds?  That would
be suggesting that the time to scroll one screen (without fontification)
is longer than your auto-repeat interval, which sounds implausible.

> That's why after you installed your change, I installed the one I had
> suggested (which tweaks the decision about when to skip redisplay and
> when to defer font-lock and relies on using jit-lock-defer-time).
> In my tests, it worked significantly better (was able to keep up).

> So I recommend you try jit-lock-defer-time set to 0 instead of using
> fast-but-imprecise-scrolling, and see if you like the
> resulting behavior.

No, I don't.  ;-)  What I see is somewhat jerky scrolling, mainly
unfontified, but with some fontification flashing on each screen some
short time (?10-100 milliseconds) before the next scroll.

What I see with fast-but-imprecise-scrolling is somewhat jerky scrolling,
but each displayed screen being fully fontified.  The delay between
drawing the screens is never more than about half a second, mostly less
than that, and the delay between releasing C-v and the screen stabilising
is likewise no more than half a second.

Also, when I attempt to disable jit-lock-defer-time (through the
customisation interface) the jit-lock-defer-timer keeps running, and the
"defer" mechanism keeps running with it.  This seems worth a bug report
in its own right.

> IIUC if Emacs can *almost* keep up, then fast-but-imprecise-scrolling
> might be just enough to let it keep up, in which case the behavior may
> look be better than with jit-lock-defer-time (because the text is never
> displayed unfontified). But if the repeat rate is faster than that, then
> jit-lock-defer-time should give noticeably better results.

I don't understand how what you're seeing is so bad.  I thought you had a
powerful workstation, a class above a typical PC, and that you had your
auto-repeat rate at a conservative figure (25 or 30 per second) rather
than the insane rate (~40 per second) I have.  I have a 5 year old
machine, not a blazingly fast super-modern one, and my window is 64 lines
deep.

fast-but-imprecise-scrolling doesn't require Emacs almost to keep up.  It
merely prevents a redisplay being directly triggered by the auto-repeated
scrolling, instead allowing a redisplay only when there is no input
waiting.  On my machine, the scrolling easily keeps up with the ~25ms
auto-repeat time.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).