Subject: bug#11496: 24.1.50; Line numbers are not redrawn correctly in linum-mode

From: Stefan Monnier <[email-masked]>
Date: Thu, 17 May 2012 09:59:55 -0400

> Would it be hard to add the "relative line number" feature with your code?

Depends on how badly you want it and how reliable you want it.
`jit-lock' is not triggered by mere cursor movement, so you need to use
another hook to detect when we move to another line, after which you'll
have to flush all the nlinum overlays and recompute them, and since we
want jit-lock to recompute them (so that all (but only) visible parts of
the buffer get recomputed), that means telling jit-lock to redo the
buffer, which will make it re-font-lock as well.
So it'll be a bit costly.

IOW, you need to hook into nlinum.el's display so it puts relative
numbers (easy), and then add something like

  (add-hook 'post-command-hook
    (lambda () (if (current-line-number-changed-p)
                   (remove-text-properties (point-min) (point-max)
                   '(fontified nil)))))

And of course, post-command-hook will not always be sufficient.

        Stefan

PS: And of course, there's the problem (also present in the linum.el hack)
that the cursor position is a window-property so when the buffer is
shown in various windows the relative line numbers may not make that
much sense in other buffers.  So maybe you'd really want this relative
numbering to be different for every window.