--- Begin Message ---
|
Subject: |
Line scrolling inconsistent with global-hl-line-mode and some font settings |
|
Date: |
Wed, 10 Jul 2013 00:48:43 -0700 |
|
User-agent: |
mu4e 0.9.9.5; emacs 24.3.1 |
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.
--- End Message ---