2

I'm using (global-linum-mode t) to present line numbers in Emacs. This works just fine up-until I use the ctrl + up/down commands (forward-paragraph and backward-paragraph) to navigate a buffer, at which point some line numbers are rendered incorrectly (see attached image). This occurs only when I use said commands to skip entire segments of code, and the issue immediately disappears (the line numbers are rendered correctly, that is) if I start navigating the buffer by other means. The issue is present in both C and C++ modes (visualized), and I'm using Emacs 24.3.1 on x86-64 Fedora 19.

While the go-to-line command serves my purposes in terms of navigating compilation errors and warnings, I'd like to keep the line numbers as I find them to be helpful in terms of quickly approximating length of functions. So far I've found no mention of this problem elsewhere, and I'm unsure of whether or not this is expected behavior of Emacs or if I'm to submit a bug report.

Has anyone encountered the issue or know anything of its origin?

enter image description here

Fix:

The problem may be resolved by invoking (linum-update-current), as portrayed by @lawlist in his answer below. An easy way of repeatedly doing this is to append the command to the execution of forward-paragraph, which may be done using the Emacs Lisp advice feature:

(defadvice forward-paragraph (after forward-paragraph-linum-update)
  "Perform (linum-update-current) after jumping forward one
  paragraph to ensure line numbers are being rendered
  correctly."
  (linum-update-current))
(ad-activate 'forward-paragraph)
Caterpillar
  • 599
  • 6
  • 20

1 Answers1

2

A few of the lead members on the Emacs development team suggest that linum-mode be avoided for a variety of reasons, and instead they suggest using nlinum-mode: http://elpa.gnu.org/packages/nlinum.html

I personally use a modified version of linum-mode, and I have fixed a few bugs -- if you keep using linum-mode, you will likely need to do the same -- i.e., implement your own bug fixes as you find them. The quickest way to fix the bug you see is to follow your command with:

(linum-update-current)
lawlist
  • 13,099
  • 3
  • 49
  • 158
  • Performing (linum-update-current) after a forward paragraph jump solved the issue; it was particularly handy to append the command using the advice-feature. I added a code sample similar to the one I used to fix the problem to your answer, I hope you don't mind! – Caterpillar Aug 22 '14 at 14:52
  • @Caterpillar -- the other forum members voted not to accept your proposed edit of the answer. Often times, what I do is edit my own question by putting three underscore symbols to create a divider line and then I write: "**EDIT (August 22, 2014)**: Created an example with `advice` using (in part) the code provided by @lawlist in the answer below. . . . ." And then I repeat the process for each new edit. I usually give credit to someone else for the answer that put me on the right track, and then I just keep improving upon my own solution as needed. – lawlist Aug 22 '14 at 16:05
  • It seems they did, although I cannot fathom why. [From what I've gathered](http://meta.stackoverflow.com/questions/255057/is-it-acceptable-to-improve-other-people-answers-to-your-own-question), there should be no issue in adding material to the answers of others. Anyhow, thank you for your response! – Caterpillar Aug 25 '14 at 17:20