bug#27281: Fix nlinum missing line numbers.

bug#27281: Fix nlinum missing line numbers.

[William Gilbert]

[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1895 bytes --]

bug#27281: Fix nlinum missing line numbers.

[npostavs]

William Gilbert <gilbertw1@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?

bug#27281: Fix nlinum missing line numbers.

[Bryan Gilbert]

On 06/10/2017 07:51 AM, npostavs@users.sourceforge.net wrote:
 > William Gilbert <gilbertw1@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.

bug#27281: Fix nlinum missing line numbers.

[Alex]

npostavs@users.sourceforge.net writes:

> William Gilbert <gilbertw1@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.

bug#27281: Fix nlinum missing line numbers.

[npostavs]

Alex <agrambot@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

bug#27281: Fix nlinum missing line numbers.

[Alex]

npostavs@users.sourceforge.net writes:

> Alex <agrambot@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?

bug#27281: Fix nlinum missing line numbers.

[npostavs]

Alex <agrambot@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.

bug#27281: Fix nlinum missing line numbers.

[Bryan Gilbert]

On 06/10/2017 06:12 PM, npostavs@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

bug#27281: Fix nlinum missing line numbers.

[Bryan Gilbert]

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.

bug#27281: Fix nlinum missing line numbers.

[Lars Ingebrigtsen]

Bryan Gilbert <gilbertw1@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