GNU bug report logs - #4996
23.1; linum mode fails to number lines properly when just scrolling buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4996 in the body.
You can then email your comments to 4996 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1; linum mode fails to number lines properly when just
   scrolling buffer
Date: Fri, 20 Nov 2009 21:30:46 -0800

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

Message #10 received at 4996 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: 4996 <at> debbugs.gnu.org
Subject: problem found
Date: Fri, 20 Nov 2009 22:06:46 -0800

    Ah!  I have figured out the problem.  report-emacs-bug adds the
intangible property to the instructions.  Normally, forward-line skips
past text with the intangible property and this is what happens when
linum-update is called normally, hence those lines do not receive line
numbers normally.  [UPDATE: this is a different bug in linum as it
normally reports incorrect line numbers in the presence of intangible
text; ironically, the case I was reporting is one of the few when it
reports the *correct* line numbers.  Consider this a bug report for the
behavior of the window-scroll-functions callers.]

    However, for some reason inhibit-point-motion-hooks is set to t when
the window-scroll-functions hooks are called.  This causes linum-update,
which uses forward-line, to number the intangible lines only when called
from the scrolling hook.

    The following code change, which fixes the bug, demonstrates this:
[UPDATE: this actually breaks linum further]

(defun linum-after-scroll (win start)
  (let ((old inhibit-point-motion-hooks))
    (setq inhibit-point-motion-hooks nil)
    (linum-update (window-buffer win))
    (setq inhibit-point-motion-hooks old)))


    I am not sure if the actual bug here is with the callers of
window-scroll-functions incorrectly setting inhibit-point-motion-hooks
or with linum-after-scroll (in which case, the documentation for
window-scroll-functions should mention this behavior).  If the later, a
better patch should be used that uses unwind-protect or the like.

- Mark

Message #15 received at 4996 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Mark Lillibridge <mark.lillibridge <at> hp.com>
To: mark.lillibridge <at> hp.com
Cc: 4996 <at> debbugs.gnu.org
Subject: Re: problem found
Date: Fri, 20 Nov 2009 22:24:17 -0800

    Ok, I have a proposed patch for linum.el that solves the problem
with it displaying incorrect line numbers in the presence of intangible
text.

The original version of linum.el has:

linum.el:129:
(defun linum-update-window (win)
  "Update line numbers for the portion visible in window WIN."
  (goto-char (window-start win))
  (let ((line (line-number-at-pos))
        (limit (window-end win t))
        (fmt (cond ((stringp linum-format) linum-format)
                   ((eq linum-format 'dynamic)
                    (let ((w (length (number-to-string
                                      (count-lines (point-min) (point-max))))))
                      (concat "%" (number-to-string w) "d")))))
        (width 0))
    (run-hooks 'linum-before-numbering-hook)
    ;; Create an overlay (or reuse an existing one) for each
    ;; line visible in this window, if necessary.
    (while (and (not (eobp)) (<= (point) limit))
      (let* ((str (if fmt
                      (propertize (format fmt line) 'face 'linum)
                    (funcall linum-format line)))
             (visited (catch 'visited
                        (dolist (o (overlays-in (point) (point)))
                          (when (equal-including-properties
				 (overlay-get o 'linum-str) str)
                            (unless (memq o linum-overlays)
                              (push o linum-overlays))
                            (setq linum-available (delq o linum-available))
                            (throw 'visited t))))))
        (setq width (max width (length str)))
        (unless visited
          (let ((ov (if (null linum-available)
                        (make-overlay (point) (point))
                      (move-overlay (pop linum-available) (point) (point)))))
            (push ov linum-overlays)
            (overlay-put ov 'before-string
                         (propertize " " 'display `((margin left-margin) ,str)))
            (overlay-put ov 'linum-str str))))
      (forward-line)
      (setq line (1+ line)))
    (set-window-margins win width)))


The problem here is the third to last line,

linum.el:164:
      (forward-line)

Linum assumes this will move at most one logical line forward, when
in the presence of intangible text it can move an arbitrary number of
logical lines forward.  *BUG*


I propose changing that line to:

      (let ((old-inhibit inhibit-point-motion-hooks))
	(setq inhibit-point-motion-hooks t)
	(forward-line)
	(setq inhibit-point-motion-hooks old-inhibit))

    I have verified that this causes the correct line numbers to be
shown, both with and without being called via the scrolling hook.


Comments?

- Mark

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Markus Triska <markus.triska <at> gmx.at>
To: gnu-emacs-bug <at> moderators.isc.org
Subject: Re: bug#4996: problem found
Date: Sat, 21 Nov 2009 09:25:11 +0100

Mark Lillibridge <mark.lillibridge <at> hp.com> writes:

> I propose changing that line to:
>
>       (let ((old-inhibit inhibit-point-motion-hooks))
> 	(setq inhibit-point-motion-hooks t)
> 	(forward-line)
> 	(setq inhibit-point-motion-hooks old-inhibit))

I suggest:

      (let ((inhibit-point-motion-hooks t))
        (forward-line))

Message #25 received at 4996-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Markus Triska <markus.triska <at> gmx.at>
Subject: Re: bug#4996: problem found
Date: Tue, 24 Nov 2009 17:28:27 -0500

>> I propose changing that line to:
>> 
>> (let ((old-inhibit inhibit-point-motion-hooks))
>> (setq inhibit-point-motion-hooks t)
>> (forward-line)
>> (setq inhibit-point-motion-hooks old-inhibit))

> I suggest:

>       (let ((inhibit-point-motion-hooks t))
>         (forward-line))

Thanks, installed,


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.