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

Previous Next

Full log

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

Previous Next

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