Subject: bug#27281: Fix nlinum missing line numbers.

From: Alex <[email-masked]>
Date: Sat, 10 Jun 2017 19:18:46 -0600

[email-masked] writes:

> Alex <[email-masked]> 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?