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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Wed, Oct 29, 2014 at 12:59:26PM -0400, Stefan Monnier wrote:
> > An approach I haven't tried yet would be to use the existing scrolling
> > functionality for discreet key presses, changing to
> > nilled-out-fontification-functions when the keystrokes are coming in at
> > auto-repeat rates.

> I think the problem is how to distinguish the two.  If we can
> distinguish the two, then we could probably use it in jit-lock-defer.

Every event has a timestamp, doesn't it?  If it doesn't, it certainly
ought to!  If two successive keyboard events are "the same", and arrive
within kbd-auto-repeat-threshold of eachother, then the first event
should be marked as auto-repeat (assuming it is still in the event
queue).

Then there needs to be an Fthis_event_is_auto_repeated which remembers
whether the event which became the most recent key-sequence is
auto-repeated.

Then a scrolling command (or similar) can test
this-event-is-auto-repeated to discover whether or not it's got enough
breathing space to do something lengthy (such as invoking functions which
want to fontify with fontification-functions intact).

Or something like that.

> More specifically, your jit-lock-defer experiment showed that the
> problem is that to get smooth scrolling, we need to skip fontification
> during the scroll even though there's no input pending (because the
> next repetition hasn't arrived yet).

Yes.

> Another way to look at it: if running CMD required to run the
> fontification functions, then we should not skip the subsequent
> redisplay even if there's input pending (this is based on the assumption
> that running the fontification functions takes the lion's share of
> redisplay time and that running the fontification function during CMD
> means that redisplay probably won't need to run the fontification
> function).  Such a heuristic might make the
> jit-lock-defer-when-input-pending work better.

Running display when there's input available is a fairly drastic change
to the command loop.  Also, something, somewhere will need to determine
whether the fontification called for CMD covers the same buffer region as
what is about to be redisplayed.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).