Re: The unwarranted scrolling assumption

[Lennart Borgman]

On Wed, Jun 16, 2010 at 2:55 AM, David De La Harpe Golden
<address@hidden> wrote:
> On 16/06/10 00:59, 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.)
>>
>
> I see this sometimes, with the recipe you outline.
>
> Sometimes emacs seems to decide to recenter, when it has "too much" input
> while display is taking its time (which I guess it might for e.g.
> font-locked window.c or a bunch of foreign scripts on view-hello-file)
>
> I found the faster I set keyboard autorepeat the easier it is to make
> happen.  e.g. with my usual "xset r rate 150 60" it happens very
> occasionally, but with "xset r rate 150 180" it happens a lot.


Just a somewhat wild guess:

I wonder if this happens in redisplay_window in xdisp.c. This
functions has a labeled called "recenter":

  /* Finally, just choose place to start which centers point */

 recenter:
  if (centering_position < 0)
    centering_position = window_box_height (w) / 2;

The intent of that label seems to be just trying to came up to speed
with the input. But that is exactly the problem here.

However I dislike the way the problem is solved. I would rather wish
that the display engine instead calculated a new window start point
from the input command queue. I have no idea if that is actually
possible.

What I can see is that redisplay_window can restart through
redisplay_internal (the comment at the label "need_larger_matrices"
says that).

Perhaps this possibility to restart can be used instead.

But this is over the head for me.


Kim, are you there? Help!