bug#16526: 24.3.50; scroll-conservatively & c-mode regression

[Eli Zaretskii]

> Date: Sat, 25 Jan 2014 19:25:32 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 16526@debbugs.gnu.org, acm@muc.de
> 
>  >> Well ... so you know why it calls back_comment around the END of the
>  >> buffer?
>  >
>  > It starts at the end of the buffer, but then moves all the way back
>  > to the beginning.
> 
> IIUC `beginning-of-buffer' does set_point_both.  Does that move all the
> way back to the beginning?

Of course not, it jumps there in one go.

>  > And yes, I know why: it's because scroll-conservatively causes
>  > redisplay to examine buffer text around point,
> 
> Where is `point' at that time?

At EOB.

>  > when it decides where
>  > to place window-start.  This is triggered by redisplay after the move
>  > to the end of the buffer.
> 
> But the `end-of-buffer' call terminates cleanly after a few seconds -
> that's what the `sit-for' proves in my code.

Right, and that's when redisplay kicks in, which invokes JIT Lock.

>  >> Not monotonously.  Sometimes it's called from the same position (for
>  >> example 948653 is at least three times on my list) again.
>  >
>  > True.  But I'm not sure this is relevant to the slow redisplay.
> 
> It hints at some really bad code embedded in really bad code.

Not necessarily.  Sometimes, this cannot be avoided.  More thorough
analysis is needed to determine whether it's really bad code.

>  >>  > This
>  >>  > happens when Emacs needs to redisplay the last portion of the buffer,
>  >>  > immediately after the call to end-of-buffer.
>  >>
>  >> Hmm ... but the problem is when going to BOB.
>  >
>  > No, going to BOB is instantaneous.  The problem happens in redisplay
>  > after going to EOB.
> 
> EOB happens before my `sit-for'.

See above.  Redisplay is separate from command execution.  So yes, we
are already at EOB, and then redisplay happens.

>  >>  > JIT Lock is triggered also when font-lock is turned on after the move
>  >>  > to end of the buffer.  But the difference seems to come from the fact
>  >>  > that under scroll-conservatively, we examine the buffer a little bit
>  >>  > above/below the window, when we decide where to put window-start.
>  >>
>  >> And somehow a "current position" is still near the end of the buffer at
>  >> that time.
>  >
>  > Yes, because Emacs is at EOB.
> 
> Why?

Because we moved there with end-of-buffer.