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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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).

If it's still in the queue, then input-pending-p will return non-nil
while it's processed, so jit-lock-defer-when-input-pending would already
handle it "right".

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

We could indeed try to recognize auto-repeat by looking at the time
since the last event, but it seems tricky to make it work well,
especially it seems tricky to correctly handle the last such event.

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

I don't think it's technically drastic.

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

My idea was to assume that it is.  At least, it seems unlikely that the
two regions would be very far apart.

My reasoning is that skipping redisplay should not be done for long
periods of time.  The reason we want to skip redisplay is to let Emacs
perform "real work" instead, but there's a tension where the user also
wants to see the intermediate states.

Also the gain from skipping redisplay depends on the ratio between "time
to run the command" compared to "time to perform redisplay".  So if the
command took a long time, skipping redisplay provides less gain.

So I think we really should force redisplay despite pending input
every once in a while.  The question is to figure out under which
circumstances this should be done, so that those extra redisplays don't
slow Emacs substantially overall (i.e. it stays a small fraction of the
over processing time) yet they do let the user see intermediate states.


        Stefan