Re: Unfreezing the display during auto-repeated scrolling. Simpler approach.

[Stefan Monnier]

>> > PageDown key.  However, on single PageDowns, the fact that the text is
>> > first displayed and only later (~0.1s) fontified could be disturbing to
>> > some people.
>> I suggested earlier to change jit-lock-defer so that deferral only takes
>> place if there's pending input.  It might take care of this case.
> It doesn't.  :-(

By "this case" I meant "the case of single page-downs".  AFAICT your
experiment focused on auto-repeating page-downs, which is a different case.

> I've set my jit-lock-defer-time to 0.03s.

I think it's better to keep it above 0.1s.

> What then happens is that some fontification requests from the scrolling
> code (NOT from display) become "non-deferred", and jit-lock fontifies
> these chunks.  By the time it's done this, there are more PageDown
> events in the input queue, so Emacs doesn't get to redisplay anything.
> The screen is frozen, but becomes free as soon as the key is released
> (within a second).  This is inadequate.

OK, so it did improve the behavior in the sense that Emacs can now keep
up with the scroll commands themselves (tho not the redisplay), so you
don't have to wait many seconds when you release the key.

But indeed, we have remaining problems.  I guess the main one is:

If we font-lock during the scroll command and that font-lock takes
a while, then by the time we get to redisplay the input queue is not
empty any more, so we end up skipping redisplay, so this font-locking
was kind of wasted.  It would have been better to either not font-lock
at all, or to font-lock during redisplay rather than during the scroll
command (since that would mean that at least redisplay does happen).

Basically if we're in jit-lock and there's input pending, there's
a pretty good chance we're not doing redisplay (since redisplay would
have been skipped if there was input pending).  More specifically, the
only case where we can have input pending in jit-lock during redisplay
is when the input arrived between the time redisplay started and the
time jit-lock gets called, and usually this time is very short.
So my idea doesn't work.

> I've tried making the C variable redisplaying_p visible in lisp (through
> the new function `redisplaying-p') and testing that in the above
> condition too, so that we only do undeferred fontification when the request
> comes from redisplay.  Aside from the objectionableness of never
> fontifying for any reason other than redisplay, this doesn't seem to
> help matters: auto-repeating PageDown rapidly scrolls all(?) buffer
> regions unfontified, but there is the ~0.1s gap between displaying the
> last screen and it being fontified.  This is also not good.

Hmm... the redisplay that happens in response to the last page-down should
perform font-lock since there's no input pending.  So I don't understand
why you see the display unfontified first, followed by fontification
0.1s later.
Oh, wait, I guess it's because the previous redisplay had its font-lock
deferred so the next 500 bytes were marked as `fontified = defer', so on
the "final" redisplay, we may font-lock some additional part of the
buffer, but there's a significant part of the visible part of the buffer
that's already been marked as `fontified = defer'.

I'm beginning to like your C-level hack.


        Stefan