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

[martin rudalics <rudalics@gmx.at>]

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

But if `beginning-of-buffer' jumps to BOB in one go how comes that
`point' at the time something "causes redisplay to examine buffer text
around point" is still at EOB?

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

If I shorten my scenario to

(progn
   (setq scroll-conservatively 101)
   (find-file (concat source-directory "src/xdisp.c"))
   (end-of-buffer)
   (sit-for 3))

it terminates here in a few seconds.  When/where exactly does redisplay
kick in in the original scenario?

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

And I see nothing bad happen until that redisplay finishes.

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

And then `beginning-of-buffer' moves `point' to `point-min' and the
trouble starts.  We probably are miscommunicating but please check once
more your claim that the problem is with redisplay after
`end-of-buffer'.  If I omit `beginning-of-buffer' from my code I can see
no problems.

martin