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

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

> Who's going to decide when a "forced" display is to take place?

That's the question, indeed.  Maybe we could simply move the
`input-pending' test so it's done before running the command.  I.e. if
there was no input pending when the command started, then don't skip
the redisplay.

For short-running commands, this will make no difference (since the
probability that input arrives right during its execution is small), but
and for long-running commands it may force redisplay even though there's
input pending, but in that case the proportion of time spent in
redisplay is smaller since the command's runtime is long.

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

That's also an option, indeed.  I don't like the sound of a preset
duration between redisplays, tho.  I'd rather measure the average
redisplay time and then use a multiple of that.

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

Yes, reality is more complex, of course.  Hard to tell what will really
work without an actual experiment.

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

Your experience has shown that jit-lock-defer-if-input-pending does let
Emacs keep up (in the sense that Emacs comes back to life when you
release the key), so I presume we'd use that, and combine it with
an occasional forced redisplay.


        Stefan