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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Mon, Oct 27, 2014 at 05:38:06PM -0400, Stefan Monnier wrote:
> >> If jit-lock-defer-time produces the desired effect,

> It doesn't, currently.  But the technique can be tweaked.

> > 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.  :-(

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

Then I tried adding this condition to jit-lock-function, so that it
looks like:

  (when (and jit-lock-mode (not memory-full))
    (if (or (null jit-lock-defer-timer)
            (not (input-pending-p)))      <================
        <un-deferred fontification>
      <deferred fontification>
	))

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.

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.

I don't think jit-lock's defer can be brought to do what we want.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).