bug#28246: display line number width != length of line number at eob

[Eli Zaretskii]

> Date: Sat, 26 Aug 2017 14:57:56 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> I would like to configure native line numbers to dynamically adjust the width 
> (smaller/larger) so that it is equal to the length of the last line in the 
> buffer.

AFAIU, this should be already supported by customizing to non-nil
values 2 options: display-line-numbers-width-start and
display-line-numbers-grow-only.  If it doesn't work for you, please
show a reproducible recipe which exhibits the wrong or unexpected
behavior.

> Emacs is erroneously increasing the line number width before there are 
> sufficient lines in the buffer to merit such an increase in width.
> 
> Emacs fails to decrease the line number width when lines are removed from the 
> buffer that merit a decrease in the width.

These are not errors, they are deliberate behavior.  With the default
automatic adjustment of the width used for line-number display, Emacs
needs to estimate the largest line number to be displayed in the
window _before_ it actually displays all the lines in the window.  The
estimation is a conservative one, and errs on the safe side, so that
the computed width is never too small, because that would produce a
horizontal shift of lines starting from some point in the middle of a
window.

This is done for speed, because the alternative would be to redisplay
the window twice, the first time to know what is the number of the
last visible line, the second time to actually display the numbers
using the right width.  We would be then back at the slow operation of
linum.el, to say nothing of the fact that such double redisplay
disrupts the normal flow of redisplay.

I don't see why the way the current implementation works is a problem,
since the point in the buffer where the width is dynamically changed
is unimportant in practice, the only requirement is that it is never
too narrow.  IOW, there's no error here, and nothing to fix.

> The desired behavior can be achieved with the Lisp code below AND by adding 
> the 
> following lines of code to maybe_produce_line_number just above the comment 
> /* 
> Compute the required width if needed.  */

>   /* example modification to achieve desired behavior */
>   if (NATNUMP (Vdisplay_line_numbers_width)
>       && !EQ (Vdisplay_line_numbers, Qrelative)
>       && !EQ (Vdisplay_line_numbers, Qvisual))
>     it->lnum_width = XFASTINT (Vdisplay_line_numbers_width);

I don't understand why you need this.  it->lnum_width is calculated
once for each window, at the beginning of every redisplay, and there
should be no need to recompute it for each screen line, like your
proposal does, because the results will be identical.  So the above is
a waste of cycles, AFAICT.

> I was unable to achieve the desired behavior by customizing Lisp variables 
> such 
> as display-line-numbers-grow-only and/or display-line-numbers-width-start.

What part(s) of the desired behavior you were unable to achieve?

> Here is the Lisp code that I am using:

This code will count lines in the buffer upon each command, which
could significantly slow down Emacs responsiveness in large buffers.
It will also increase the line-number display width when stuff is
added to the end of buffer even if that portion of the buffer is never
displayed, something that might surprise users.  By contrast, the
existing facilities recount the line numbers only when needed, and
make a point of reusing the results of previous such calculation when
possible (compare your display-line-numbers--update-width-fn with
display-line-numbers-update-width in display-line-numbers.el).

So while it is okay to have this in your personal customizations, I'm
not sure others will want this behavior, and it certainly cannot be
the default.