bug#4996: 23.1; linum mode fails to number lines properly when just scrolling buffer

[Mark Lillibridge]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:


    In emacs, invoke report-emacs-bug :-) while global-linum-mode is on.
Observe that there is some kind of overlay that occupies 9 lines before
this point.  That is, the spot where this paragraph starts is labeled
line 7.  Now page down (^v) and back (esc v).  Observe that now every
display line, including inside the overlay, has a line number.  *BUG*
What was line 7 is now shown as line 17.

    As soon as you do another command like a right arrow, the line
numbers revert to the original correct line numbering.


Linum has a hook for window-scroll-functions:

linum.el:74:
(define-minor-mode linum-mode
  "Toggle display of line numbers in the left margin."
  :lighter ""                           ; for desktop.el
  (if linum-mode
      (progn
        (if linum-eager
            (add-hook 'post-command-hook (if linum-delay
                                             'linum-schedule
                                           'linum-update-current) nil t)
          (add-hook 'after-change-functions 'linum-after-change nil t))
        (add-hook 'window-scroll-functions 'linum-after-scroll nil t)
        (add-hook 'window-size-change-functions 'linum-after-size nil t)
        (add-hook 'change-major-mode-hook 'linum-delete-overlays nil t)
        (add-hook 'window-configuration-change-hook
                  'linum-after-config nil t)
        (linum-update-current))


linum.el:175:
(defun linum-after-scroll (win start)
  (linum-update (window-buffer win)))


If I disable this function by doing (via {esc}:):

(defun linum-after-scroll (win start)
  t)

the bug goes away.  


    I am investigating further, but the problem appears to be that
forward-line acts differently during window-scroll-functions hook then
normally.  Some sort of dynamic variable binding, perhaps?

- Mark