Re: The unwarranted scrolling assumption

[Lennart Borgman]

On Thu, Jun 17, 2010 at 9:23 PM, Eli Zaretskii <address@hidden> wrote:
>> From: Lennart Borgman <address@hidden>
>> Date: Thu, 17 Jun 2010 21:10:55 +0200
>> Cc: address@hidden, address@hidden
>>
>> > Please show a recipe starting from "emacs -Q".
>>
>> I am sorry, I thought that was clear. Just open a large C file for
>> example, like window.c. Set the variables as suggested earlier in this
>> thread that should prevent "jumping scrolling".
>>
>> Then just hold down or rapidly press the down arrow. You will see (if
>> your pc is not too fast) that Emacs does the "jumping scrolling" now
>> and then. Not every time, but now and then, probably when it gets
>> behind in screen updating.
>
> It doesn't jump for me.

Good for you, but why do you say that? Why is that interesting here???

> And, if the machine is too slow and cannot
> keep up with the keyboard's autorepeat rate, then what's wrong with
> the "jumps"?  What would you want Emacs to do instead, if it cannot
> keep up with the input?

Just do as it does with my patch. The same as for all other apps I
know. Continue scrolling without jumping. (At the speed it can of
course.)

>> I said that clip_changed is used only by the display routines. Only
>> those routines knows exactly what data was used when redisplay was
>> done.
>>
>> Clipping is part of the data that might influence redisplay. Changing
>> clipping might invalidate what is displayed or it may not.
>>
>> In the current code (without my patch) there is a very rough guess
>> about this: "if clipping is change we should invalidate the display of
>> every window".
>>
>> So this is what `narrow-to-region' and `widen' did by setting clip_changed 
>> to 1.
>
> But narrow-to-region and widen are not part of the recipe, so how can
> they influence scrolling in this case?

What do you mean? They are both used in Emacs could and there is a lot
of calls to them during scrolling.

Probably that is from font locking.

>> However when I came to think about this I wondered if the display of
>> a buffer in several windows is in some (magic) way connected. I
>> don't think they are, but anyway I ask you: are they?
>
> It is connected via the buffer-local variables.  I'm not sure this is
> what you wanted to hear, but your question is too broad.

Sorry. I meant if there was something special in the display routines
themselves for the connection.

I doubt that there are, but there could be some optimization.

> Anyway, I don't think it's an efficient way of debugging this -- by
> you asking me questions based on some assumptions which I'm not sure
> are correct.  Let's stick to trying to understand why scrolling is
> rejected by redisplay in favor of recentering (see my other mail).

I have already explained that. Can you please before you suggest new
things try to understand what I have written. Just ask if you do not
understand.