Re: The unwarranted scrolling assumption

[Eli Zaretskii <eliz@gnu.org>]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Fri, 18 Jun 2010 00:16:33 +0200
> Cc: emacs-devel@gnu.org
> 
> > 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.

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.

> 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 I don't think we should accept this patch without understanding
what problem causes the recentering in the original situation you
reported.

> - Then if I just hold down the down arrow it can happen after a while.
> - My output shows that it is because try_scrolling failed.

try_scrolling may legitimately fail in some cases.

> Some variables as I see them now at the recenter: label in redisplay_window:
>   scroll_step == 1
>   temp_scroll_step == 0
>   current_buffer->clip_changed ==0   Why current_buffer, there is a
> variable buffer here?
>   current_buffer->scroll_up_aggressively == 45459482, same down
> 
> 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.

> 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.