Re: The unwarranted scrolling assumption

[Lennart Borgman]

On Fri, Jun 18, 2010 at 9:54 AM, Eli Zaretskii <address@hidden> wrote:
>> From: Lennart Borgman <address@hidden>
>> Date: Fri, 18 Jun 2010 00:16:33 +0200
>> Cc: address@hidden
>>
>> > Again, PLEASE answer my questions, if you really want my help in
>> > understanding this issue.  What parts of the above condition prevented
>> > reconsider_clip_changes from resetting b->clip_changed to zero?  If
>> > needed, please re-run under GDB (without your patches) and see what
>> > other factors are at work here.
>>
>> I can now answer you question again since I have found a new way to
>> make "jumping scrolling" appear. However the situation above is not
>> involved, at least not directly, since ->clip_changed is 0. (I think
>> there is an unused global variable clip_changed that is not used.)
>
> So what you describe is a different situation altogether, and doesn't
> help to understand your original report and the patch that is supposed
> to fix it.


Yes and no.

If you look at my other messages you can see there are two distinct
bugs that I have seen that leads to the "jumping scrolling" (the
problem with clip_changed and the bug regarding visual-line-mode).

To clear things out I think it would be good if you (and anyone
interested) looked at the patch I have sent first. I have tried to
explain why I did this patch so please reread my messages first if
something is unclear.


> Emacs uses the recenter as the last resort, and it does this in many
> different situations.  Discovering another situation where it happens
> does not help to understand the one you discovered before, and the
> patch to correct it (assuming we want that) might be entirely
> different.  This just adds confusion.


I can see that this is confusing if still find my patch unclear.

So at least now it is clear that I think there are two distinct bugs
that leads to "jumping scrolling" (which I think is a better
description than "recentering").


>> The situation is now this:
>> - I am using my patch (in the state I sent it here).
>> - I have seen no problem with the patch (but as I said I think there
>> is one problem though it has not shown up).
>> - It is quite hard to make Emacs do the "jumping scrolling".
>>
>> So it is better, still there are problems.
>
> It may be "better" in the use-cases you tried.  But without
> understanding the original problem and why your patch fixes it, it is
> quite likely that the patch will introduce other redisplay problems.


So you think that the patch may introduce redisplay problems? That
concern is good, but can you seen something in the patch that you
think will cause problems?

Maybe it helps if I explain that the patch is not about how the screen
is updated. It is only about when it is updated. At least that was my
intention.


> try_scrolling may legitimately fail in some cases.


Maybe, but I do not think that is the problem here.


>> BTW, the use of current_buffer here seems to me to be a bug.
>
> No, it isn't a bug.  When redisplay works on a window, current_buffer
> is bound to the buffer displayed by the window.  See the call to
> set_buffer_internal_1 near the beginning of redisplay_window.


Thanks. I missed that. Then it is just a matter of style. I really
think that using current_buffer there is not the best.


>> I guess an interesting part may be why clear_glyph_matrix failed. Do
>> you think there is something interesting there?
>
> I just see normal operation of the display engine.  The condition
>
>  w->cursor.vpos < 0
>
> means that try_window failed to find the cursor position after
> redisplaying the window, because point is not inside the window.
>
> IOW, try_scrolling tried to redisplay the window by reusing some of
> the results of the previous redisplay, but found that doing so would
> produce a window that does not include point.  So it gives up.  This
> is normal.


Thanks, that is good to know, but I think there is a bug in this case.
Can you please reread the message where I talked about how to
reproduce this around line 702 in window.c?