bug#14567: These changes sometimes break plain text navigation

[Dima Kogan <dima@secretsauce.net>]

Hi. I'm seeing the patches meant to address this bug break plain-text
scrolling. I'm reporting this new issue here, since it seems on-topic.
I'm running a close-to-HEAD emacs on a Debian box. The most recent
change to simple.el is this:

http://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/simple.el?id=a7484019a30de380087389ccc8e5b0d0b8dae290

I'm observing that under some specific conditions (ones that my .emacs
just happens to hit) C-f can get stuck scrolling text instead of going
to the next line. To make the bug happen, I do this:

1. Load a text file. This is plain ASCII. No images or unicode or
   anything interesting. A nice test case is the output of 'seq 1000'

2. Press C-f repeatedly until the point reaches the bottom of the
   screen; this works fine

3. When at the bottom of the screen C-f scrolls the text one line up,
   while keeping the point where it was in the buffer. Now the point
   gets stuck, and subsequent C-f/C-b just scroll the screen; the point
   is stuck.


The bug requires particular .emacs settings. I wittled it down to this:

(custom-set-variables
 '(default-frame-alist
    '((font . "-adobe-courier-medium-r-normal--14-100-100-100-m-90-iso8859-1")))
 '(inhibit-startup-screen t))

(global-hl-line-mode)


The inhibit-startup-screen is there to be nicer; may not be required for
the bug. The (global-hl-line-mode) is significant. The bug doesn't
happen without it. That font is significant also. Other fonts seem to
work without the bug. I suspect the window sizes are significant as
well. I can see the bug if I launch 'emacs -geometry 30x30'. The
width/height of the emacs window as reported by xwininfo is then
308x455.

This is 100% reproducible for me. I suspect it may not be so for others.
Let me know if I should run any specific tests to get to the bottom of
this.

Thanks