Subject: Re: bug#14567: These changes sometimes break plain text navigation

From: Eli Zaretskii <[email-masked]>
Date: Sat, 06 Jul 2013 14:02:43 +0300

> From: Dima Kogan <[email-masked]>
> Date: Sat, 06 Jul 2013 02:02:16 -0700
> 
> 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.

You mean, "C-x =" reports the same value no matter how many times you
press C-f or C-b?

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

Thanks, but I cannot follow this recipe, since I don't have that font.
And with a few other fonts I tried, I cannot reproduce the problem.

Moreover, the changes in this bug report are not supposed to affect
C-f/C-b in any way.  If you revert the changes in simple.el introduced
in revision 112998, does this problem go away?

Does any file reproduces the problem, or only some?  E.g., does
xdisp.c from the Emacs sources reproduce it?  If not, what is special
about the files you use to reproduce the problem?  Is the last line
only partially visible, per chance?  If you set auto-window-vscroll to
nil, does the problem still happen?

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

Well, not being dependent on a particular font would be a start.  An
easier reproducing recipe would be even better.

Thanks.