GNU bug report logs - #27281
Fix nlinum missing line numbers.

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 27281 in the body.
You can then email your comments to 27281 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: William Gilbert <gilbertw1 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Fix nlinum missing line numbers.
Date: Wed, 7 Jun 2017 17:46:29 -0400

[Message part 1 (text/plain, inline)]

I've been working to track to down a bug where line numbers are
occasionally missing when using nlinum mode. Currently there is a package
written to workaround the problem that has a picture and description of the
problem: https://github.com/hlissner/emacs-nlinum-hl.

After extensive debugging I've tracked the problem down to the
'nlinum--region' function. Specifically the while loop check that
determines if '(point)' is less than the limit. I've found that the problem
exists when '(point)' is exactly equal to 'limit'. In this scenario the
loop terminates and the last line in the region is not provided with a line
number. I was able to remedy the problem by changing the condition from
'less than' to 'less than or equal to', which will allow the last line in
the region to be properly assigned a line number.

Thank you.

Diff:

diff --git a/packages/nlinum/nlinum.el b/packages/nlinum/nlinum.el
index ca4f949fc..f82b61987 100644
--- a/packages/nlinum/nlinum.el
+++ b/packages/nlinum/nlinum.el
@@ -303,7 +303,7 @@ it may cause the margin to be resized and line numbers
to be recomputed.")
       (remove-overlays (point) limit 'nlinum t)
       (let ((line (nlinum--line-number-at-pos)))
         (while
-            (and (not (eobp)) (< (point) limit)
+            (and (not (eobp)) (<= (point) limit)
                  (let* ((ol (make-overlay (point) (1+ (point))))
                         (str (funcall nlinum-format-function
                                       line nlinum--width))

[Message part 2 (text/html, inline)]

Message #8 received at 27281 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: William Gilbert <gilbertw1 <at> gmail.com>
Cc: 27281 <at> debbugs.gnu.org
Subject: Re: bug#27281: Fix nlinum missing line numbers.
Date: Sat, 10 Jun 2017 07:51:17 -0400

William Gilbert <gilbertw1 <at> gmail.com> writes:

> I've been working to track to down a bug where line numbers are
> occasionally missing when using nlinum mode. Currently there is a package
> written to workaround the problem that has a picture and description of the
> problem: https://github.com/hlissner/emacs-nlinum-hl.
>
> After extensive debugging I've tracked the problem down to the
> 'nlinum--region' function. Specifically the while loop check that
> determines if '(point)' is less than the limit. I've found that the problem
> exists when '(point)' is exactly equal to 'limit'. In this scenario the
> loop terminates and the last line in the region is not provided with a line
> number.

Do you know how to reproduce this scenario?

> I was able to remedy the problem by changing the condition from
> 'less than' to 'less than or equal to', which will allow the last line in
> the region to be properly assigned a line number.

This sounds like a workaround, possibly to a bug in jit-lock.  Or
perhaps we need to return a list of the form (jit-lock-bounds BEG END)
from nlinum--region?

Message #11 received at 27281 <at> debbugs.gnu.org (full text, mbox):

From: Bryan Gilbert <gilbertw1 <at> gmail.com>
Cc: 27281 <at> debbugs.gnu.org
Subject: Re: bug#27281: Fix nlinum missing line numbers.
Date: Sat, 10 Jun 2017 10:35:29 -0400

On 06/10/2017 07:51 AM, npostavs <at> users.sourceforge.net wrote:
> William Gilbert <gilbertw1 <at> gmail.com> writes:
>
>> I've been working to track to down a bug where line numbers are
>> occasionally missing when using nlinum mode. Currently there is a 
package
>> written to workaround the problem that has a picture and description 
of the
>> problem: https://github.com/hlissner/emacs-nlinum-hl.
>>
>> After extensive debugging I've tracked the problem down to the
>> 'nlinum--region' function. Specifically the while loop check that
>> determines if '(point)' is less than the limit. I've found that the 
problem
>> exists when '(point)' is exactly equal to 'limit'. In this scenario the
>> loop terminates and the last line in the region is not provided with 
a line
>> number.
>
> Do you know how to reproduce this scenario?

I don't know how to easily and reliably reproduce this problem. I 
normally encounter it at least once every few minutes. I've reproduced 
the problem in my configuration, which is a derivative of the doom 
configuration (https://github.com/hlissner/.emacs.d), and using 
spacemacs with nlinum enabled. I don't know if there is anything 
specific to those two configurations that makes the problem present 
itself more frequently, but using one of those setups you should see the 
problem relatively quickly.

I lucked out and had a saved perspective (persp-mode) that exhibited 
this problem every time I loaded it, which was what allowed me to 
reliably debug the problem.

>
>> I was able to remedy the problem by changing the condition from
>> 'less than' to 'less than or equal to', which will allow the last 
line in
>> the region to be properly assigned a line number.
>
> This sounds like a workaround, possibly to a bug in jit-lock. Or
> perhaps we need to return a list of the form (jit-lock-bounds BEG END)
> from nlinum--region?

I am not familiar with jit-lock and am still all around very much a 
novice with elisp and emacs. I essentially zeroed in on the problem, but 
instrumenting some of the nlinum functions with print messages. I still 
have the perspective and underlying files preserved that replicate this 
problem everytime I load them. If there is anything you would like me to 
test or debug, please let me know. I will try to dig a little deeper to 
understand nlinum's interaction with jit-lock.

Message #14 received at 27281 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: npostavs <at> users.sourceforge.net
Cc: William Gilbert <gilbertw1 <at> gmail.com>, 27281 <at> debbugs.gnu.org
Subject: Re: bug#27281: Fix nlinum missing line numbers.
Date: Sat, 10 Jun 2017 11:44:26 -0600

npostavs <at> users.sourceforge.net writes:

> William Gilbert <gilbertw1 <at> gmail.com> writes:
>
>> I've been working to track to down a bug where line numbers are
>> occasionally missing when using nlinum mode. Currently there is a package
>> written to workaround the problem that has a picture and description of the
>> problem: https://github.com/hlissner/emacs-nlinum-hl.
>>
>> After extensive debugging I've tracked the problem down to the
>> 'nlinum--region' function. Specifically the while loop check that
>> determines if '(point)' is less than the limit. I've found that the problem
>> exists when '(point)' is exactly equal to 'limit'. In this scenario the
>> loop terminates and the last line in the region is not provided with a line
>> number.
>
> Do you know how to reproduce this scenario?
>
>> I was able to remedy the problem by changing the condition from
>> 'less than' to 'less than or equal to', which will allow the last line in
>> the region to be properly assigned a line number.
>
> This sounds like a workaround, possibly to a bug in jit-lock.  Or
> perhaps we need to return a list of the form (jit-lock-bounds BEG END)
> from nlinum--region?

FWIW I've encountered this issue before and this diff does not solve the
problem for me. I mostly see it when using the 3rd-party package
macroexpand with nlinum. Expanding and closing a macro will leave
several lines with no line number (from the 2nd line of the macro until
the last line of the macro).

I've tried to use edebug on nlinum--region to figure out what's going
on, but it doesn't seem to be triggering for some reason.

Message #17 received at 27281 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Alex <agrambot <at> gmail.com>
Cc: William Gilbert <gilbertw1 <at> gmail.com>, 27281 <at> debbugs.gnu.org
Subject: Re: bug#27281: Fix nlinum missing line numbers.
Date: Sat, 10 Jun 2017 18:12:38 -0400

Alex <agrambot <at> gmail.com> writes:
>>
>> This sounds like a workaround, possibly to a bug in jit-lock.  Or
>> perhaps we need to return a list of the form (jit-lock-bounds BEG END)
>> from nlinum--region?
>
> FWIW I've encountered this issue before and this diff does not solve the
> problem for me. I mostly see it when using the 3rd-party package
> macroexpand with nlinum. Expanding and closing a macro will leave
> several lines with no line number (from the 2nd line of the macro until
> the last line of the macro).
>
> I've tried to use edebug on nlinum--region to figure out what's going
> on, but it doesn't seem to be triggering for some reason.

I suspect the debugger is suppressed while jit-lock occurs.  You would
need to log things silently and print it later.  I think
'jit-lock--run-functions' and 'jit-lock-fontify-now' would be
interesting targets.  Something easy to check would be if there are
certain values of 'jit-lock-functions' needed to trigger this (apart
from nlinum--region of course).  Here's my guess as to a fix (untested):

--- i/packages/nlinum/nlinum.el
+++ w/packages/nlinum/nlinum.el
@@ -296,7 +296,8 @@ (defun nlinum--region (start limit)
   (save-excursion
     ;; Text may contain those nasty intangible properties, but
     ;; that shouldn't prevent us from counting those lines.
-    (let ((inhibit-point-motion-hooks t))
+    (let ((inhibit-point-motion-hooks t)
+          (end start))
       (goto-char start)
       (unless (bolp) (forward-line 1))
       (remove-overlays (point) limit 'nlinum t)
@@ -320,9 +321,10 @@ (defun nlinum--region (start limit)
                    ;;   (run-with-idle-timer 0.5 nil #'nlinum--flush-overlays
                    ;;                        (current-buffer)))
                    (setq line (1+ line))
-                   (zerop (forward-line 1))))))))
-  ;; (setq nlinum--desc (format "-%d" (nlinum--ol-count)))
-  nil)
+                   (setq end (line-end-position))
+                   (zerop (forward-line 1)))))))
+    ;; (setq nlinum--desc (format "-%d" (nlinum--ol-count)))
+    `(jit-lock-bounds ,start . ,end)))
 
 ;;;###autoload
 (define-globalized-minor-mode global-nlinum-mode nlinum-mode

Message #20 received at 27281 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: npostavs <at> users.sourceforge.net
Cc: William Gilbert <gilbertw1 <at> gmail.com>, 27281 <at> debbugs.gnu.org
Subject: Re: bug#27281: Fix nlinum missing line numbers.
Date: Sat, 10 Jun 2017 19:18:46 -0600

npostavs <at> users.sourceforge.net writes:

> Alex <agrambot <at> gmail.com> writes:
>>>
>>> This sounds like a workaround, possibly to a bug in jit-lock.  Or
>>> perhaps we need to return a list of the form (jit-lock-bounds BEG END)
>>> from nlinum--region?
>>
>> FWIW I've encountered this issue before and this diff does not solve the
>> problem for me. I mostly see it when using the 3rd-party package
>> macroexpand with nlinum. Expanding and closing a macro will leave
>> several lines with no line number (from the 2nd line of the macro until
>> the last line of the macro).
>>
>> I've tried to use edebug on nlinum--region to figure out what's going
>> on, but it doesn't seem to be triggering for some reason.
>
> I suspect the debugger is suppressed while jit-lock occurs.  You would
> need to log things silently and print it later.  I think
> 'jit-lock--run-functions' and 'jit-lock-fontify-now' would be
> interesting targets.

Well, in my case it seems that nlinum--region is being fed wrong
start/limit values.

> Something easy to check would be if there are
> certain values of 'jit-lock-functions' needed to trigger this (apart
> from nlinum--region of course).  Here's my guess as to a fix (untested):

That doesn't work in my case. However, for me the problem might be
because of macrostep using with-silent-modifications. To test, calling 

  (with-silent-modifications (delete-region (point) (scan-sexps (point) 1)))

on an sexp and there will be missing line number(s).

This only affects nlinum, and not linum. Is it possible to work around
this in nlinum while still using with-silent-modifications?

Message #23 received at 27281 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Alex <agrambot <at> gmail.com>
Cc: William Gilbert <gilbertw1 <at> gmail.com>, 27281 <at> debbugs.gnu.org
Subject: Re: bug#27281: Fix nlinum missing line numbers.
Date: Sat, 10 Jun 2017 21:37:32 -0400

Alex <agrambot <at> gmail.com> writes:

> That doesn't work in my case. However, for me the problem might be
> because of macrostep using with-silent-modifications.

Ah, that sounds like a bug in macrostep then.  Not really the same as
this one.

> This only affects nlinum, and not linum. Is it possible to work around
> this in nlinum while still using with-silent-modifications?

Not sure, but why does macrostep with-silent-modifications while
changing the buffer?  ... Oh, according to
https://github.com/joddie/macrostep/issues/2 it's to avoid modifying the
buffer status; that doesn't seem like the right way to do it.  I will
follow up there.

Message #26 received at 27281 <at> debbugs.gnu.org (full text, mbox):

From: Bryan Gilbert <gilbertw1 <at> gmail.com>
To: npostavs <at> users.sourceforge.net
Cc: Alex <agrambot <at> gmail.com>, 27281 <at> debbugs.gnu.org
Subject: Re: bug#27281: Fix nlinum missing line numbers.
Date: Sat, 10 Jun 2017 22:37:04 -0400

On 06/10/2017 06:12 PM, npostavs <at> users.sourceforge.net wrote:
> I suspect the debugger is suppressed while jit-lock occurs.  You would
> need to log things silently and print it later.  I think
> 'jit-lock--run-functions' and 'jit-lock-fontify-now' would be
> interesting targets.  Something easy to check would be if there are
> certain values of 'jit-lock-functions' needed to trigger this (apart
> from nlinum--region of course).  Here's my guess as to a fix (untested):
Applying that fix seemed to solve the problem! I had to make a slight 
modification to put the 'jit-lock-bounds' function call inside the 
'let', but other than that it seems to work well. I've yet to see the 
problem since applying the patch and my 'bad' perspective worked 
properly as well.

Here's the slightly modified diff:

diff --git a/packages/nlinum/nlinum.el b/packages/nlinum/nlinum.el
index ca4f949fc..82872d571 100644
--- a/packages/nlinum/nlinum.el
+++ b/packages/nlinum/nlinum.el
@@ -297,7 +297,8 @@ it may cause the margin to be resized and line 
numbers to be recomputed.")
   (save-excursion
     ;; Text may contain those nasty intangible properties, but
     ;; that shouldn't prevent us from counting those lines.
-    (let ((inhibit-point-motion-hooks t))
+    (let ((inhibit-point-motion-hooks t)
+          (end start))
       (goto-char start)
       (unless (bolp) (forward-line 1))
       (remove-overlays (point) limit 'nlinum t)
@@ -321,9 +322,10 @@ it may cause the margin to be resized and line 
numbers to be recomputed.")
                    ;;   (run-with-idle-timer 0.5 nil 
#'nlinum--flush-overlays
                    ;;                        (current-buffer)))
                    (setq line (1+ line))
-                   (zerop (forward-line 1))))))))
+                   (setq end (line-end-position))
+                   (zerop (forward-line 1))))))
   ;; (setq nlinum--desc (format "-%d" (nlinum--ol-count)))
-  nil)
+  `(jit-lock-bounds ,start . ,end)))

 ;;;###autoload
 (define-globalized-minor-mode global-nlinum-mode nlinum-mode

Message #29 received at 27281 <at> debbugs.gnu.org (full text, mbox):

From: Bryan Gilbert <gilbertw1 <at> gmail.com>
To: npostavs <at> users.sourceforge.net
Cc: Alex <agrambot <at> gmail.com>, 27281 <at> debbugs.gnu.org
Subject: Re: bug#27281: Fix nlinum missing line numbers.
Date: Sat, 10 Jun 2017 22:50:09 -0400

On 06/10/2017 10:37 PM, Bryan Gilbert wrote:
> Applying that fix seemed to solve the problem! I had to make a slight 
> modification to put the 'jit-lock-bounds' function call inside the 
> 'let', but other than that it seems to work well. I've yet to see the 
> problem since applying the patch and my 'bad' perspective worked 
> properly as well.
Sorry, I spoke too soon. I didn't realize it, but I had a 'def-advice' 
in my config that overrode the 'nlinum--region' function. Using your 
patch didn't actually solve the problem. I'll try and dig a little more.

Message #34 received at 27281 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Bryan Gilbert <gilbertw1 <at> gmail.com>
Cc: 27281 <at> debbugs.gnu.org, Alex <agrambot <at> gmail.com>,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#27281: Fix nlinum missing line numbers.
Date: Sun, 29 Sep 2019 17:04:34 +0200

Bryan Gilbert <gilbertw1 <at> gmail.com> writes:

> On 06/10/2017 10:37 PM, Bryan Gilbert wrote:
>> Applying that fix seemed to solve the problem! I had to make a
>> slight modification to put the 'jit-lock-bounds' function call
>> inside the 'let', but other than that it seems to work well. I've
>> yet to see the problem since applying the patch and my 'bad'
>> perspective worked properly as well.
> Sorry, I spoke too soon. I didn't realize it, but I had a 'def-advice'
> in my config that overrode the 'nlinum--region' function. Using your 
> patch didn't actually solve the problem. I'll try and dig a little more.

More information was requested, but no response was given within a few
years, so I'm closing this bug report.  If the problem still exists,
please reopen this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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