unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alex <agrambot@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: Native display of line numbers, improved
Date: Mon, 26 Jun 2017 13:36:40 -0600	[thread overview]
Message-ID: <871sq65ynr.fsf@lylat> (raw)
In-Reply-To: <83efu6spyk.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 26 Jun 2017 18:56:03 +0300")

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Mon, 26 Jun 2017 11:28:23 -0400
>> 
>> I don't understand your comment: Alex is referring here to the approach
>> used in nlinum, which I chose specifically to avoid having to scan the
>> whole buffer.
>
> I alluded to this:
>
>> that can
>> be worked around by setting 'display-line-number-width' to a
>> sufficiently large number, but I would like it to be no larger than what
>> it needs to be for the current text in the buffer.
>
> I provided 'display-line-number-width' to cater to the desire of not
> shrinking the width too much, and it seemed to me that if someone's
> ideal is not to change the width at all, as Alex said up-thread,
> counting the lines at the beginning will do that for him.

Counting at the beginning helps a lot, but it doesn't help for when the
buffer grows over an editing session.

>> Basically, start with a small value of display-line-number-width, and if
>> during display we find that this value is too small to fit the largest
>> displayed line-number, we increase it.
>
> I wanted to avoid using a buffer-local variable settable by the
> display engine.  (I cannot easily use display-line-number-width,
> because that's a user-settable option; I need another variable.)

What's the difference between the display engine setting a buffer-local
variable and Lisp libraries doing so?

I've included a diff that accomplishes what I want. Is there something
fundamentally wrong it?

PS: There's a bug with tab stops when display-line-number-width is a
small positive number. Look at around L20814 in xdisp.c with a
display-line-number-width being nil, 1, 2, and 3.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: line-numbers-grow-only.diff --]
[-- Type: text/x-diff, Size: 1755 bytes --]

diff --git a/src/xdisp.c b/src/xdisp.c
index aa75fcaf77..442b09b10b 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -20810,8 +20810,21 @@ maybe_produce_line_number (struct it *it)
   /* Compute the required width if needed.  */
   if (!it->lnum_width)
     {
-      if (NATNUMP (Vdisplay_line_number_width))
-	it->lnum_width = XFASTINT (Vdisplay_line_number_width);
+      if (display_line_numbers_grow_only && NATNUMP (Vdisplay_line_number_width))
+	{
+	  int min_lnum = XFASTINT (Vdisplay_line_number_width);
+	  ptrdiff_t max_lnum;
+
+	  max_lnum = this_line + it->w->desired_matrix->nrows - 1 - it->vpos;
+	  min_lnum = max (log10 (max_lnum) + 1, min_lnum);
+
+	  it->lnum_width = min_lnum;
+	  Vdisplay_line_number_width = make_number (min_lnum);
+	}
+      else if (NATNUMP (Vdisplay_line_number_width))
+	{
+	  it->lnum_width = XFASTINT (Vdisplay_line_number_width);
+	}
       else
 	{
 	  /* Max line number to be displayed cannot be more than
@@ -32495,6 +32508,14 @@ even if the actual number needs less space.
 The default value of nil means compute the space dynamically.
 Any other value is treated as nil.  */);
   Vdisplay_line_number_width = Qnil;
+  DEFSYM (Qdisplay_line_number_width, "display-line-number-width");
+  Fmake_variable_buffer_local (Qdisplay_line_number_width);
+
+  DEFVAR_BOOL ("display-line-numbers-grow-only", display_line_numbers_grow_only,
+	       doc: /* Non-nil means only dynamically grow the
+display, and never shrink. This variable is only taken into account
+when `display-line-number-width' is a positive number.*/);
+  display_line_numbers_grow_only = false;
 
   DEFVAR_BOOL ("inhibit-eval-during-redisplay", inhibit_eval_during_redisplay,
     doc: /* Non-nil means don't eval Lisp during redisplay.  */);

      parent reply	other threads:[~2017-06-26 19:36 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-24 17:27 Native display of line numbers, improved Eli Zaretskii
2017-06-24 18:40 ` Clément Pit-Claudel
2017-06-24 18:51   ` Eli Zaretskii
2017-06-24 20:53 ` Stephen Berman
2017-06-25 14:07   ` Eli Zaretskii
2017-06-25 14:34     ` Stephen Berman
2017-06-25 15:10       ` Eli Zaretskii
2017-06-25 15:41         ` Stephen Berman
2017-06-25 16:02           ` Eli Zaretskii
2017-06-25 19:00             ` Stephen Berman
2017-06-24 21:23 ` Stephen Berman
2017-06-25 14:03   ` Eli Zaretskii
2017-06-25 14:34     ` Stephen Berman
2017-06-25 14:57       ` Eli Zaretskii
2017-07-17 22:20       ` line-number-mode at EOB (was: Native display of line numbers, improved) Stephen Berman
2017-07-18  4:16         ` line-number-mode at EOB Stefan Monnier
2017-07-18 14:04           ` Stephen Berman
2017-07-18 14:30             ` Stefan Monnier
2017-07-18 14:51               ` Eli Zaretskii
2017-07-18 15:04                 ` Stefan Monnier
2017-07-20 20:25                   ` Paul Eggert
2017-07-20 20:43                     ` Stephen Berman
2017-07-20 21:19                       ` Paul Eggert
2017-07-20 21:35                         ` Stephen Berman
2017-07-18 14:55         ` line-number-mode at EOB (was: Native display of line numbers, improved) Eli Zaretskii
2017-07-18 16:33           ` line-number-mode at EOB Stephen Berman
2017-07-18 19:03             ` Eli Zaretskii
2017-07-18 20:38               ` Stephen Berman
2017-06-25  9:59 ` Native display of line numbers, improved martin rudalics
2017-06-25 13:54   ` Eli Zaretskii
2017-06-25 15:58     ` martin rudalics
2017-06-25 20:30 ` Alex
2017-06-26  2:39   ` Eli Zaretskii
2017-06-26  3:43     ` Alex
2017-06-26  3:50       ` Alex
2017-06-26 14:58         ` Eli Zaretskii
2017-06-26 19:41           ` Alex
2017-06-27 14:25             ` Eli Zaretskii
2017-06-29 20:25               ` Native line numbers column disappears at times Kaushal Modi
2017-06-30  6:00                 ` Eli Zaretskii
2017-07-10 18:53                   ` Kaushal Modi
2017-07-10 19:31                     ` Eli Zaretskii
2017-07-10 20:56                       ` Kaushal Modi
2017-06-26 14:54       ` Native display of line numbers, improved Eli Zaretskii
2017-06-26 15:28         ` Stefan Monnier
2017-06-26 15:56           ` Eli Zaretskii
2017-06-26 16:12             ` Stefan Monnier
2017-06-26 16:26               ` Eli Zaretskii
2017-06-26 19:36             ` Alex [this message]

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=871sq65ynr.fsf@lylat \
    --to=agrambot@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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).