Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3

[Dmitry Gutov]

On 10.04.2020 20:46, Stefan Monnier wrote:
> > When the last repetition is executed, the behavior seems fine already if the
> > value is 0. What I see is "flickering" during scrolling, while C-v is still
> > pressed.
>
> Hmmm... I don't know why you see "flickering" during the scrolling, indeed.
>
> And I'm surprised you don't see "flickering" on the last repetition: the
> way jit-lock-defer-time works, when input-pending-p is non-nil, jit-lock
> marks the chunk as fontified (which is a lie), and this chunk will
> always go past `window-end`, so on the last repetition the beginning of
> the window is not passed to jit-lock at all (because it was part of the
> last chunk of the previous call to jit-lock, with input-pending = true),
> and it only gets fontified a bit later via the timer.

Perhaps the answer is the same as why I do see mostly fontified 
screenfuls while scrolling, even with jit-lock-defer-time=0. Like... 
idle timers manage to run from time to time?

Similarly, I usually don't see a flicker right after visiting a file. 
Only sometimes. Do you?

> That's one of the main advantages of the way
> `fast-but-imprecise-scrolling` works: it doesn't lie about having
> fontified that chunk.

Is there a downside to that strategy? What would happen if jit-lock 
didn't apply the 'defer' value in this case?

> Along the lines of what you proposed, I just tried the patch below,
> which is a bit like (setq jit-lock-defer-mode 0) but without the idle timer.
> It's not quite right either, tho (e.g. `emacs -Q src/xdisp.c` fails to font-lock
> the initial window, tho it does get font-locked as soon as I move the
> cursor).

I also had to make input_was_pending non-static to make it work.

The result is I see a lot more unfontified screenfuls when scrolling 
(which is a minus), but scrolling is even faster now (but it was fast 
with previous patches or f-b-i-s already). Further, it almost certainly 
suffers from the same same problem that makes 
fast-but-imprecise-scrolling apparently unsuitable for being a default 
(loss of precision). The main plus there being that it *can* keep up 
with the keyboard's repeat rate.

But I wonder if anyone would want to scroll this quickly when they can't 
read this fast anyway (or even briefly scan through the contents of the 
windows that fly by).