Re: The unwarranted scrolling assumption

[Stefan Monnier]

>>> Stop reading input until it catches its breath.

This has two problems, depending on the precise solution used:
- if we don't flush the "overflowing input", then this input
  accumulates, and you end up waiting for your scroll to keep scrolling
  long after you've stopped pressing the key.
- if we do flush the overflowing input, then the user ends up having to
  be careful not to type too fast, lest Emacs will ignore some of the
  keys she presses (could be some keys in the middle of a key-sequence).
So I don't think it's a good solution.  Emacs was designed to handle
a slow redisplay by suspending redisplay when it's too slow to avoid the
above problems.  I think it's a very sound design and don't want to try
and change it, because redisplay has always been on the critical path and
I don't see that changing in the future.

> Which is likely too much work for little gain, so I'm not really
> pushing for this to be implemented; fortunately my computer can
> currently keep up with scrolling.

I think there are several things we can do here:
1 - improve the scrolling behavior such that it doesn't recenter when
    the user specified that it wants line-by-line scrolling.  I hope
    this thread will find a solution to this problem.
2 - speed up redisplay such that the problem occurs less often.
    That would be of benefit in many more cases.
3 - Often redisplay is just fast enough except on a few occasions, and
    some of those occasions are calls to the GC, so making the GC
    faster or asynchronous would help (i.e. optimize up GC code, make it
    generational, or concurrent, younameit, but also try and reduce
    memory allocation to run the GC less often).


        Stefan