Eli Zaretskii writes: >> From: Stefan Monnier >> Date: Mon, 26 Jun 2017 11:28:23 -0400 >> >> 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. > > I alluded to this: > >> 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. > > I provided 'display-line-number-width' to cater to the desire of not > shrinking the width too much, and it seemed to me that if someone's > ideal is not to change the width at all, as Alex said up-thread, > counting the lines at the beginning will do that for him. Counting at the beginning helps a lot, but it doesn't help for when the buffer grows over an editing session. >> 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. > > I wanted to avoid using a buffer-local variable settable by the > display engine. (I cannot easily use display-line-number-width, > because that's a user-settable option; I need another variable.) What's the difference between the display engine setting a buffer-local variable and Lisp libraries doing so? I've included a diff that accomplishes what I want. Is there something fundamentally wrong it? PS: There's a bug with tab stops when display-line-number-width is a small positive number. Look at around L20814 in xdisp.c with a display-line-number-width being nil, 1, 2, and 3.