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

[martin rudalics <rudalics@gmx.at>]

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

 > And yes, I know why: it's because scroll-conservatively causes
 > redisplay to examine buffer text around point,

Where is `point' at that time?

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

 >>  > What I see is that find_defun_start is called many times,
 >>
 >> ... 530 times as I mentioned earlier ...
 >>
 >>  > with its
 >>  > first argument moving from _end_ of the buffer backwards.
 >>
 >> 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.

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

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

martin