all messages for Emacs-related lists mirrored at yhetil.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

* 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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.