Re: Native display of line numbers, improved

[Stefan Monnier <monnier@iro.umontreal.ca>]

Hi Eli,

I don't understand your comment: Alex is referring here to the approach
used in nlinum, which I chose specifically to avoid having to scan the
whole buffer.

Basically, start with a small value of display-line-number-width, and if
during display we find that this value is too small to fit the largest
displayed line-number, we increase it.  So when you open a very large
buffer (but where only the first 60 lines are displayed), only 2 columns
will be used for line-numbers since "it's been enough so far"; if you
move to line 2000 and back, we'll now be using 4 columns (even though
2 would be sufficient).  This means that column 0 does sometimes change,
but fairly rarely (only when you move to a line number with more digits
than what you've visited so far).


        Stefan


>> >> 1. An option to never dynamically shrink 'display-line-number-width'
>> >>    while still dynamically growing. I dislike having column 0 constantly
>> >>    changing, so an option to only grow the width dynamically like in
>> >>    (n)linum would be very appreciated.
>> >
>> > How is growing different from shrinking?  Just wondering.
>> 
>> Growing is necessary in the case where the width of the new line(s)
>> exceeds the current 'display-line-number-width'. Of course that can
>> be worked around by setting 'display-line-number-width' to a
>> sufficiently large number, but I would like it to be no larger than what
>> it needs to be for the current text in the buffer.

> You could do that by counting lines in the buffer in some suitable
> hook, and then setting the value of 'display-line-number-width'
> accordingly, right?

> My point is that doing what you want requires counting lines in the
> entire buffer, something that could take a considerable time.  So
> doing that in the display code when people who'd like that could set
> that up for them using the existing facilities sounds uneconomical.