Re: The unwarranted scrolling assumption

[Lennart Borgman]

On Wed, Jun 16, 2010 at 11:17 PM, Eli Zaretskii <address@hidden> wrote:
>> From: Lennart Borgman <address@hidden>
>> Date: Wed, 16 Jun 2010 03:40:11 +0200
>> Cc: address@hidden
>>
>> 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.
>
> No, it's not just to keep up.  Recentering is the generic redisplay
> method, used as the last resort if Emacs is unable to be smarter than
> that.

Is not that the same thing 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.
>
> I think it's impossible.  How can you guess the effect of list of
> arbitrary input events on the display, without actually redisplaying?

In a general case this is impossible, but we know more here.

>> What I can see is that redisplay_window can restart through
>> redisplay_internal (the comment at the label "need_larger_matrices"
>> says that).
>
> need_larger_matrices means that the dimensions of the window changed
> drastically, e.g. if the text uses smaller fonts.  In that case, the
> current redisplay cycle is aborted, and Emacs reallocates the glyph
> matrices to fit the new dimensions.

Thanks, yes I saw that. I just wondered if the state was interrupt-able.

>> Perhaps this possibility to restart can be used instead.
>
> You will end up with the same recenter anyway, after redisplay is
> re-entered.

Hm, yes, that is what I wonder. ;-)

I am not sure. I am trying to fix it some way, but there is still
something I do not understand.