bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anders Lindgren
Subject: bug#16129: 24.3.50; Emacs slow with follow-mode when buffer ends before last window
Date: Mon, 6 Jan 2014 09:20:03 +0100

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 <address@hidden> wrote:
> Date: Mon, 6 Jan 2014 00:13:38 +0100
> From: Anders Lindgren <address@hidden>
> Cc: address@hidden
>
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]