Re: The unwarranted scrolling assumption

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

On Thu, Jun 17, 2010 at 8:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Thu, 17 Jun 2010 20:32:27 +0200
>> Cc: emacs-devel@gnu.org, david@harpegolden.net
>>
>> Several of us has said that the problem is easily reproduceable.
>
> 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.

>> The conclusions are based on the logic of the source code. But you
>> seem to think they are unwarranted. Can you please explain what part
>> of the patches you think are unwarranted or unexplained?
>
> I cannot explain anything yet, because I cannot follow your reasoning
> and thus cannot assess the changes you suggest.  That's why I asked
> the questions you didn't answer.

Hi Eli,

I will try to explain, but a problem for me is that I do not know
where to start when explaining. You did not comment on the explanation
I gave with the patches. So I just do it the best I can. Please just
tell me what you do not understand.


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.

I removed that guess and made another, a little bit less rough guess:
"if clipping is not the same as when last redisplay was done we should
invalidate the display".

This is (nearly) on the safe side. It invalidate the display even if
the changes in clipping actually does not need to invalidate the
display.


If something above is unclear then please ask. I now have questions to you.

As you can see above there are two a bit weak points in the last
paragraph of my explanation. The last part is a bit more easy so I
start with that. Is there an easy way to find out if the change in the
clipping data did not invalidate the display? That could be great.

Now to the more problematic part. This patch is not yet finished
because there is one thing that I have forgotten to fix after testing:
I have implemented this in redisplay_window, i.e. the cashing of the
clipping should have been per window, but it is per buffer at the
moment.

I guess that this is quite easy to fix by moving the cashing of the
clipping data to the window instead. 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?