bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#28246: display line number width != length of line number at eob
Date: Mon, 28 Aug 2017 20:27:46 +0300

> Date:  Sun, 27 Aug 2017 18:46:42 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  28246@debbugs.gnu.org
> 
> I do not know whether any other Emacs users would appreciate *precision* 
> width based upon the length of the last line in the buffer.

You are the first to raise this issue, and frankly I still don't
understand why it's important to you.

> Inasmuch as I was hoping to achieve *precision* width every command loop, 
> display-line-numbers-width-start and/or display-line-numbers-grow-only would 
> not suffice in that regard.  I am uncertain why it->lnum_width is *not* 
> always equal to
> 
>   (save-excursion
>     (goto-char (point-max))
>     (length (format-mode-line "%l"))

Because we only make the line-number display as wide as needed for
line numbers seen so far, while the Lisp above wants to make it as
wide as required by the last line in the buffer.  You can get the same
with the above customization variables if you visit the bottom of the
buffer just once.

> linum.el is slow in large buffers primarily because it uses count-lines.  In 
> an emacs.stackexchange.com thread entitled "A faster method to obtain 
> `line-number-at-pos` in large buffers" -- 
> https://emacs.stackexchange.com/q/3821/2287 -- I learned that 
> format-mode-line with the "%l" argument can be used to greatly enhance speed 
> versus using count-lines.  However, the window must be visible and some other 
> limitations apply as discussed in the comments of the SE thread.

As that discussion reveals, this method is not 100% reliable in
practice.

Anyway, is there anything else to do in this bug report, or can we
close it?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]