bug#9324: 24.0.50; Movement past end of screen causes weird jump

[Eli Zaretskii <eliz@gnu.org>]

> From: Ivan Andrus <darthandrus@gmail.com>
> Date: Sat, 20 Aug 2011 14:29:30 +0200
> 
> >> Aaargh!  After running the progn, do you see all of line starting with 208, or just the continuation of it.
> > 
> > Neither.  The top line in the window is this:
> > 
> >  (custom-set-faces '(mode-line ((t (:box (:line-width 1))))))
> > 
> > If you see something else, your frame must be much larger than mine.
> 
> But it should have set up the frame size to be the same!?  I have
> 
> (cons (frame-parameter nil 'height) (frame-parameter nil 'width))
> (47 . 89)
> 
> Does setting the frame size not work the same way in Windows?

No, it works the same.  However, AFAIR you cannot trust changes in
frame parameters to take effect immediately, only on the next
redisplay cycle.  If you evaluate the frame parameter changes before
the progn, does the problem still happen?

> Sorry, I started debugging immediately after I evaluated the forward-sexp so that's where the point ought to be.

But then what you observed in the debugger is not related at all to
the issue at hand, does it?

> lpoint and opoint were optimized away, but FWIW I got the following in both situations:
> 
> (gdb) ppt
> BUF PT: 2418 of 1..2419 GAP: 2419 SZ=2000
> 
> 
> (gdb) p startp
> $3 = {
>   charpos = 0, 
>   bytepos = 4320351914
> }

I don't believe these values, I'm quite sure they are wrong because
the build is optimized.

> > Anyway, you should be able to tell which of the conditions got
> > new_vpos set by looking at the values of w->cursor.vpos and
> > w->frozen_window_start_p.
> 
> (gdb) p w->cursor.vpos
> $6 = -1
> (gdb) p w->frozen_window_start_p
> $7 = 0
> 
> so that means new_vpos = window_box_height (w) / 2;

I will only believe what the debugger shows in a non-optimized build.
Please use "-ggdb -g3" in the compiler switches, to force GCC to
produce as much debug info as possible.