bug#14836: Line scrolling inconsistent with global-hl-line-mode and some font settings

bug#14836: Line scrolling inconsistent with global-hl-line-mode and some font settings

[Dima Kogan]

I am observing that under some specific conditions, the scrolling of
lines in a buffer is inconsistent. If I'm looking at a buffer of plain
ASCII text (the output of 'seq 1000' say), and I press C-n repeatedly,
eventually the point reaches the end of the screen. Then the screen
should scroll by 50%, leaving the point in the middle. This is the
default emacs behavior.

I am seeing that with specific settings I get a different behavior, that
scrolls approximately by one line at a time (details below).

I'm running a very recent build of emacs; the most recent change to
lisp/simple.el is

 http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=abd9896b6e601368ef1f7a5174979e189a3f4d68

This is a recent Debian/unstable box.

The .emacs is

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

This font and (global-hl-line-mode) are significant to manifest the bug.

This bug report was originally discussed in http://debbugs.gnu.org/14567
Fixes to that bug also fixed other, related reports:

 http://debbugs.gnu.org/6103
 http://debbugs.gnu.org/6272
 http://debbugs.gnu.org/14598


To trigger the bug I do the following (may depend on my window manager,
font system, screen resolution, etc):

1. launch emacs with the .emacs above
2. open a file that's the output of 'seq 1000'
3. make the text larger by pressing C-x C-+ four times
4. navigate to the bottom by pressing C-n repeatedly

As soon as C-n breaks the screen boundary, the buffer should scroll the
screen by 50%. Instead I see these 2 behaviors alternate with each C-n
press at the bottom of the screen:

- Screen scrolls by 1 line, revealing one new previously-cut-off line at
  the bottom. The point does NOT move, meaning (point) returns the same
  value before and after the C-n. The visual indication of the point
  does move, since it scrolls together with the text.

- The point moves to this newly-visible line. Nothing scrolls


I looked at some pertinent values when this happens to try to shed some
light on the behavior:

 (defun doreport ()
   (let ((report (format (concat "(point): %s\n"
                                 "(pos-visible-in-window-p t nil t): %s\n"
                                 "(posn-at-point): %s\n"
                                 "(default-font-height): %s\n")
                                 (point) (pos-visible-in-window-p t nil t)
                                 (posn-at-point) (default-font-height))))
     (with-current-buffer "*scratch*"
       (insert report))))

When the point is sitting on a line such that the next C-n would scroll
by one line while leaving the point stationary (doreport) says:

 (point): 112
 (pos-visible-in-window-p t nil t): (0 902 0 15 7 41)
 (posn-at-point): (#<window 0x1138430 on dat> 112 (0 . 880) 0 nil 112 (0 . 40) nil (0 . 0) (15 . 22))
 (default-font-height): 22

Immediately after such a scroll-only motion (and right before C-n would
simply move the point by one line without scrolling) (doreport) says:

 (point): 112
 (pos-visible-in-window-p t nil t): (0 902 0 15 7 41)
 (posn-at-point): (#<window 0x1138430 on dat> 112 (0 . 858) 0 nil 112 (0 . 39) nil (0 . 0) (15 . 22))
 (default-font-height): 22

I can reproduce this reliably, so please ask if more probes would be
useful.

bug#14836: Line scrolling inconsistent with global-hl-line-mode and some font settings

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Date: Wed, 10 Jul 2013 00:48:43 -0700
> 
> - Screen scrolls by 1 line, revealing one new previously-cut-off line at
>   the bottom. The point does NOT move, meaning (point) returns the same
>   value before and after the C-n. The visual indication of the point
>   does move, since it scrolls together with the text.
> 
> - The point moves to this newly-visible line. Nothing scrolls
> 
> 
> I looked at some pertinent values when this happens to try to shed some
> light on the behavior:
> 
>  (defun doreport ()
>    (let ((report (format (concat "(point): %s\n"
>                                  "(pos-visible-in-window-p t nil t): %s\n"
>                                  "(posn-at-point): %s\n"
>                                  "(default-font-height): %s\n")
>                                  (point) (pos-visible-in-window-p t nil t)
>                                  (posn-at-point) (default-font-height))))
>      (with-current-buffer "*scratch*"
>        (insert report))))
> 
> When the point is sitting on a line such that the next C-n would scroll
> by one line while leaving the point stationary (doreport) says:
> 
>  (point): 112
>  (pos-visible-in-window-p t nil t): (0 902 0 15 7 41)
>  (posn-at-point): (#<window 0x1138430 on dat> 112 (0 . 880) 0 nil 112 (0 . 40) nil (0 . 0) (15 . 22))
>  (default-font-height): 22
> 
> Immediately after such a scroll-only motion (and right before C-n would
> simply move the point by one line without scrolling) (doreport) says:
> 
>  (point): 112
>  (pos-visible-in-window-p t nil t): (0 902 0 15 7 41)
>  (posn-at-point): (#<window 0x1138430 on dat> 112 (0 . 858) 0 nil 112 (0 . 39) nil (0 . 0) (15 . 22))
>  (default-font-height): 22
> 
> I can reproduce this reliably, so please ask if more probes would be
> useful.

Please apply the patch below, run the recipe, and post here the
results you get in the *Messages* buffer.

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2013-07-10 16:18:17 +0000
+++ lisp/simple.el	2013-07-10 16:31:59 +0000
@@ -4821,6 +4821,9 @@ The value is a floating-point number."
 		     (< rowh dlh))
 		(setq last-line (min (- wslines scroll-margin) vpos))
 	      (setq last-line (min (- wslines scroll-margin 1) (1- vpos)))))
+	(message "vs %s dlh %s this %s rowh %s rbot %s py %s vpos %s last %s"
+		 (window-vscroll nil t)
+		 dlh this-height rowh rbot py vpos last-line)
 	(cond
 	 ;; If last line of window is fully visible, and vscrolling
 	 ;; more would make this line invisible, move forward.
@@ -4828,6 +4831,7 @@ The value is a floating-point number."
 		   (null this-height)
 		   (<= this-height dlh))
 	       (or (null rbot) (= rbot 0)))
+	  (message "1")
 	  nil)
 	 ;; If cursor is not in the bottom scroll margin, and the
 	 ;; current line is is not too tall, move forward.
@@ -4835,12 +4839,14 @@ The value is a floating-point number."
 	       vpos
 	       (> vpos 0)
 	       (< py last-line))
+	  (message "2")
 	  nil)
 	 ;; When already vscrolled, we vscroll some more if we can,
 	 ;; or clear vscroll and move forward at end of tall image.
 	 ((> vs 0)
 	  (when (or (and rbot (> rbot 0))
 		    (and this-height (> this-height dlh)))
+	    (message "3")
 	    (set-window-vscroll nil (+ vs dlh) t)))
 	 ;; If cursor just entered the bottom scroll margin, move forward,
 	 ;; but also optionally vscroll one line so redisplay won't recenter.
@@ -4859,14 +4865,17 @@ The value is a floating-point number."
 	  ;; discrepancies between that and DLH.
 	  (if (and rowh rbot (>= (- (+ rowh rbot) dlh) 1))
 	      (set-window-vscroll nil dlh t))
+	  (message "4, vs %s" (window-vscroll nil t))
 	  (line-move-1 arg noerror to-end)
 	  t)
 	 ;; If there are lines above the last line, scroll-up one line.
 	 ((and vpos (> vpos 0))
+	  (message "5")
 	  (scroll-up 1)
 	  t)
 	 ;; Finally, start vscroll.
 	 (t
+	  (message "6")
 	  (set-window-vscroll nil dlh t)))))))
 
 

bug#14836: Line scrolling inconsistent with global-hl-line-mode and some font settings

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

> Please apply the patch below, run the recipe, and post here the
> results you get in the *Messages* buffer.

Hi Eli.

This patch doesn't apply.

I have the latest simple.el from git:

 http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=abd9896b6e601368ef1f7a5174979e189a3f4d68

Several hunks in that patch are missing their context lines. For
instance there's no "setq last-line" in simple.el even though the first
hunk references it.

bug#14836: Line scrolling inconsistent with global-hl-line-mode and some font settings

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: 14836@debbugs.gnu.org
> Date: Wed, 10 Jul 2013 10:14:50 -0700
> 
> This patch doesn't apply.
> 
> I have the latest simple.el from git:
> 
>  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=abd9896b6e601368ef1f7a5174979e189a3f4d68
> 
> Several hunks in that patch are missing their context lines. For
> instance there's no "setq last-line" in simple.el even though the first
> hunk references it.

The git repo is not up-to-date yet.  Either use bzr or wait for a
while.

bug#14836: Line scrolling inconsistent with global-hl-line-mode and some font settings

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dima Kogan <dima@secretsauce.net>
>> Cc: 14836@debbugs.gnu.org
>> Date: Wed, 10 Jul 2013 10:14:50 -0700
>> 
>> This patch doesn't apply.
>> 
>> I have the latest simple.el from git:
>> 
>>  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=abd9896b6e601368ef1f7a5174979e189a3f4d68
>> 
>> Several hunks in that patch are missing their context lines. For
>> instance there's no "setq last-line" in simple.el even though the first
>> hunk references it.
>
> The git repo is not up-to-date yet.  Either use bzr or wait for a
> while.

Aha. Right you are. The bzr repo has rev 113360, which you just
committed; this was done after I made this bug report. That revision
appears to fix this bug. Thanks! Do you still want me to apply the patch
in the last email to tell you the probe results, or are you satisfied
now that I can't reproduce the issues?

Thanks again
dima

bug#14836: Line scrolling inconsistent with global-hl-line-mode and some font settings

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: 14836@debbugs.gnu.org
> Date: Wed, 10 Jul 2013 10:43:01 -0700
> 
> That revision appears to fix this bug. Thanks! Do you still want me
> to apply the patch in the last email to tell you the probe results,
> or are you satisfied now that I can't reproduce the issues?

No, if the bug is fixed, just close this bug report.

bug#14836: Fixed

[Dima Kogan]

Revision 113360 appears to fix this bug. Thanks.