unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Keith David Bershatsky <esq@lawlist.com>
Cc: 28246@debbugs.gnu.org
Subject: bug#28246: display line number width != length of line number at eob
Date: Mon, 28 Aug 2017 20:27:46 +0300	[thread overview]
Message-ID: <83a82j4n71.fsf@gnu.org> (raw)
In-Reply-To: <m2inh8sbul.wl%esq@lawlist.com> (message from Keith David Bershatsky on Sun, 27 Aug 2017 18:46:42 -0700)

> 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	other threads:[~2017-08-28 17:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-26 21:57 bug#28246: display line number width != length of line number at eob Keith David Bershatsky
2017-08-27 14:23 ` Eli Zaretskii
2017-08-28  1:46 ` Keith David Bershatsky
2017-08-28 17:27   ` Eli Zaretskii [this message]
2017-08-28 18:50 ` Keith David Bershatsky
2017-08-29 15:00   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83a82j4n71.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=28246@debbugs.gnu.org \
    --cc=esq@lawlist.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).