Re: The unwarranted scrolling assumption

[Lennart Borgman <lennart.borgman@gmail.com>]

On Wed, Jun 16, 2010 at 2:29 AM, Chad Brown <yandros@mit.edu> wrote:
>
> On Jun 15, 2010, at 4:59 PM, Lennart Borgman wrote:
>
> All I do to check this is open window.c and then hit/hold down the
> down arrow key (or "j" in viper).
>
> Does this work without "jumping scrolling" for you? (You have to test
> for a while, the jumping does not happen always. I is a bit like
> playing a computer game.)
>
> This can be a function of computer speed -- the settings make emacs try to
> keep up the scrolling, but if the cursor motion gets ahead of the scrolling,
> it chooses to jump-scroll rather than silently eating the scrolling.
> Caveat: this is my `basic' understanding; I haven't tested exactly these
> settings.


I think you are right, it seems to be working that way.


> What would you like Emacs to do, conceptually, if you move down lines faster
> than the display engine can redraw them?


I think it would be better if Emacs just skipped redrawing and then
come back to correct output as it would look if it had been able to
redraw everything in time.

If it worked that way you could much more easily understand what is
happening (especially for the case when you are not looking at the
point where the cursor is). You could then just pause and wait if you
noticed that Emacs was behind. There would be no big surprises.

Is there perhaps already an option for this type of scrolling behavior?


> I assume `scroll less' and `error'
> are both obvious non-starters, so I'm guessing that you would want emacs to
> remain syncronous, even if it meant being unresponsive in a
> scroll-redraw-repeat loop; is that correct?


Conceptually synchronous, but it could skip to redraw some pictures.

Looking at it this way I wonder if there is a bug/weakness in the
display engine that prevents it from interrupting a display that has
not been finished. Anyone knows about that?


> *Chad