bug#14567: These changes sometimes break plain text navigation

[Dima Kogan <dima@secretsauce.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dima Kogan <dima@secretsauce.net>
>> 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?

First off, there was a very important brain fart in what I just said. I
meant C-n/C-p instead of C-f/C-b everywhere in this bug report. Oops.
This was probably the worst way to mess up this bug report. Hopefully it
makes a bit more sense now. Sorry.

C-x = does report the same value with C-n/C-p pressed as long as there
is room to scroll; if we're already looking at the start of the
document, then C-p does the normal unbugged thing, since it can't scroll
back any further.


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

Like I said above, I badly flubbed the report; it's actually about
C-n/C-p. And yes; reverting that revision makes things work again.


> Does any file reproduces the problem, or only some?  E.g., does
> xdisp.c from the Emacs sources reproduce it?

Any file does it. I use the output of `seq 1000`, which is not very
special.


> Is the last line only partially visible, per chance?

No. The edge of the buffer looks like it aligns with the bottom edge of
the last line of text, at least to my eye. If I mess with the displayed
text more by pressing C-x C-+ several times then the last line IS only
partially visible. Then I get the same point-getting-stuck behavior, but
it recovers after a handful of scroll-only C-n presses. The exact number
depends on window size, font size, how many times C-x C-+ was pressed,
etc.


> If you set auto-window-vscroll to nil, does the problem still happen?

No. That fixes it.


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

I suspect this is font-dependent because it has something to do with the
pixel height of the font text. Can you reproduce by keeping whaever font
you're using and pressing C-x C-+ a few times? As I described earlier
this usually sticks the point for only a few C-n presses, but it's
probably the same issue.


I just did some minor debugging by adding a trace to
(window-line-height) with (trace-function-background). If I turn off
global-hl-line-mode, then the bug goes away, and (window-line-height)
appears to return reasonable values. With global-hl-line-mode,
(window-line-height) and (window-line-height -1) both return nil
supposedly. Not sure how line-move-partial could keep working without
error in that case, but that's what it says.


> Thanks.

Thank YOU!