bug#16129: 24.3.50; Emacs slow with follow-mode when buffer ends before last window

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 6 Jan 2014 00:13:38 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: 16129@debbugs.gnu.org
> 
> When "redisplay_window" is called, it goes into the case where
> "try_cursor_movement" is called.
> 
> Inside this routine, the row is picked up. The row (when using the TUTORIAL
> example) has start and end at 46229. The point and last_point, however, are
> 46228, so it assumes that the point haven't moved since the last redisplay.
> 
> Clearly, "last_point" and "row" are not consistent with each other, which
> is assumed by try_cursor_movement (if I read it correctly).
> 
> The routine first declare this to be a "success" (in the neither forward
> nor backward case). Later in the function it comes to the following
> statement:
> 
>   if (PT < MATRIX_ROW_START_CHARPOS (row)
>       || PT > MATRIX_ROW_END_CHARPOS (row))
> 
> This fails, making the function return " CURSOR_MOVEMENT_MUST_SCROLL",
> which is turn cause "redisplay_window" to recenter the window.

Thanks.  Your description is correct, and I already found that this is
what happens.  (The silence doesn't necessarily mean no one is doing
anything about the bug report ;-)

I didn't yet have the time to figure out why the last_point field of
the window is equal to point, while last_cursor_vpos points to the
screen line that does not contain point; my current suspicion is that
the post-command-hook somehow causes that.  But given that this is
what happens, you will always see a recenter, because it means Emacs
lost track of where point is in the window.  When Emacs is confused
about this, it always recenters as the last resort.

This still doesn't say why redisplay is so slow in this case, which
was the initial bug reported here.  Stay tuned.