From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#28246: display line number width != length of line number at eob Date: Sun, 27 Aug 2017 17:23:29 +0300 Message-ID: <837exp5btq.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1503843909 24640 195.159.176.226 (27 Aug 2017 14:25:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 27 Aug 2017 14:25:09 +0000 (UTC) Cc: 28246@debbugs.gnu.org To: Keith David Bershatsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 27 16:25:04 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dlyUp-00065B-DV for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Aug 2017 16:25:03 +0200 Original-Received: from localhost ([::1]:32889 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dlyUw-0000th-7x for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Aug 2017 10:25:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dlyTv-00009C-H1 for bug-gnu-emacs@gnu.org; Sun, 27 Aug 2017 10:24:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dlyTq-0007a7-Jq for bug-gnu-emacs@gnu.org; Sun, 27 Aug 2017 10:24:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49282) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dlyTq-0007a3-Fl for bug-gnu-emacs@gnu.org; Sun, 27 Aug 2017 10:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dlyTq-0007Ra-A0 for bug-gnu-emacs@gnu.org; Sun, 27 Aug 2017 10:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Aug 2017 14:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28246 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28246-submit@debbugs.gnu.org id=B28246.150384382728594 (code B ref 28246); Sun, 27 Aug 2017 14:24:02 +0000 Original-Received: (at 28246) by debbugs.gnu.org; 27 Aug 2017 14:23:47 +0000 Original-Received: from localhost ([127.0.0.1]:57963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dlyTb-0007R8-2Z for submit@debbugs.gnu.org; Sun, 27 Aug 2017 10:23:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39915) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dlyTZ-0007Qw-Lm for 28246@debbugs.gnu.org; Sun, 27 Aug 2017 10:23:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dlyTQ-0007UD-VT for 28246@debbugs.gnu.org; Sun, 27 Aug 2017 10:23:40 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dlyTQ-0007U7-RQ; Sun, 27 Aug 2017 10:23:36 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2772 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dlyTQ-0005uu-4J; Sun, 27 Aug 2017 10:23:36 -0400 In-reply-to: (message from Keith David Bershatsky on Sat, 26 Aug 2017 14:57:56 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:136257 Archived-At: > Date: Sat, 26 Aug 2017 14:57:56 -0700 > From: Keith David Bershatsky > > 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.