Hi!

I think the incorrect state occurs when the new early exit occurs from
redsplay_window. When I added the condition "&& PT == w->last_point", both
the recentering problem and speed issues were solved. However, I don't know
if this is the correct way to handle this, or if it breaks anything else.

    -- Anders


On Mon, Jan 6, 2014 at 4:45 AM, Eli Zaretskii <eliz@gnu.org> wrote:

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