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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Wed, Oct 29, 2014 at 09:49:27PM -0400, Stefan Monnier wrote:

[ ... ]

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

Let's just say that what I wrote last night was utter rubbish.  We cannot
handle the last event differently, because when we start handling it, the
next event has not yet failed to arrive.  My scheme from last night can
deliver nothing more than `input-pending-p' already can.

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

Who's going to decide when a "forced" display is to take place?  We
could, I suppose, set a flag in window_scroll when there's no pending
input, and for the command loop to detect this flag and use it to give
preference to display over reading keys.

But we don't know what command is invoking window_scroll.  It might
easily be a user written command for which premature display is not
wanted. 

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

I think that's fair enough.

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

So maybe a timer (?0.2s) could be inserted into the command loop, such
that if Emacs has been processing commands for that long since the last
redisplay, redisplay will be done in preference to processing the next
command.

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

That's not quite so clear when it's font-locking which is taking the
time, since it happens both in command processing and display.

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

Coming back to scrolling through xdisp.c, merely forcing a redisplay from
time to time isn't going to help the slowness of the scrolling.  Either
eliminating most of the fontification or speeding it up radically (as Eli
would prefer) is necessary.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).