bug#18545: 24.4.50: Bug - forward-line inside with-selected-window

[martin rudalics <rudalics@gmx.at>]

 > Can you tell me how to reproduce this?  I don't see this in the recipe
 > you described in your bug report.

I can reproduce something similar here but it hardly makes sense to
share my recipe.  The bug manifests itself such that after an implicit
`forward-line' the cursor appears stuck in a partially visible line at
the bottom of a window.  That window has a sibling on the right.  On
Windows these siblings must be in the lower half of a split frame.  On
Gtk no vertical splitting is needed.  The cursor continues to move by
one line when keeping the down key (which implicitly runs `forward-line'
here) pressed for some three seconds and gets stuck again immediately.

Some additional particularities:

(1) The bug is not reproducible with Emacs 24-4, only with current
     trunk.

(2) My settings are needed and must be in .emacs.  Starting emacs -Q,
     putting my .emacs contents in *scratch* and doing an `eval-buffer'
     there does not reproduce it.

(3) My frame must be fully maximized.  Any other form of maximization
     doesn't trigger it.

(4) Your patch doesn't fix it.  A breakpoint set there is never hit.

The bug might be related to your changes from 2014-07-09.  For example
the following excerpt from a gdb session seems suspicious (the build is
with your patch but it doesn't matter):


(gdb) break xdisp.c:16261
Breakpoint 3 at 0x1050f51: file xdisp.c, line 16261.
[...]
(gdb) bt
#0  redisplay_window (window=..., just_this_one_p=false) at xdisp.c:16261
#1  0x0104a340 in redisplay_window_0 (window=...) at xdisp.c:14322
#2  0x01191406 in internal_condition_case_1 (bfun=0x104a30a <redisplay_window_0>, arg=..., handlers=..., hfun=0x104a2e6 <redisplay_window_error>) at eval.c:1368
#3  0x0104a2cb in redisplay_windows (window=...) at xdisp.c:14302
#4  0x0104a280 in redisplay_windows (window=...) at xdisp.c:14296
#5  0x0104a280 in redisplay_windows (window=...) at xdisp.c:14296
#6  0x01049291 in redisplay_internal () at xdisp.c:13901
#7  0x01047276 in redisplay () at xdisp.c:13181
#8  0x01104bad in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x82f7ef, end_time=0x0) at keyboard.c:2594
#9  0x0111297b in read_key_sequence (keybuf=0x82f8e4, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9178
#10 0x01102665 in command_loop_1 () at keyboard.c:1467
#11 0x011912f3 in internal_condition_case (bfun=0x11022e0 <command_loop_1>, handlers=..., hfun=0x1101b4b <cmd_error>) at eval.c:1344
#12 0x01101f96 in command_loop_2 (ignore=...) at keyboard.c:1198
#13 0x01190892 in internal_catch (tag=..., func=0x1101f72 <command_loop_2>, arg=...) at eval.c:1105
#14 0x01101f50 in command_loop () at keyboard.c:1177
#15 0x011016e7 in recursive_edit_1 () at keyboard.c:787
#16 0x011018a4 in Frecursive_edit () at keyboard.c:858
#17 0x010ff600 in main (argc=1, argv=0xa32808) at emacs.c:1643

Lisp Backtrace:
"redisplay_internal (C function)" (0x206c3b4)
(gdb) p new_vpos
$1 = 426
(gdb) p w->cursor.y
$2 = 432
(gdb)

In this particular case the display should be scrolled since otherwise
point ends up on the partially visible line.  But the test

	  if (new_vpos >= w->cursor.y)

fails to trigger that.

martin