GNU bug report logs - #31717
26.1; display-line-numbers-mode enlarges indicator without need

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Carlos Pita <carlosjosepita@HIDDEN>; Keywords: notabug; dated Tue, 5 Jun 2018 02:36:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 31717 <at> debbugs.gnu.org:


Received: (at 31717) by debbugs.gnu.org; 5 Jun 2018 15:44:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 05 11:44:27 2018
Received: from localhost ([127.0.0.1]:35379 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fQE8J-00058W-6P
	for submit <at> debbugs.gnu.org; Tue, 05 Jun 2018 11:44:27 -0400
Received: from eggs.gnu.org ([208.118.235.92]:54707)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1fQE8H-00058H-H2
 for 31717 <at> debbugs.gnu.org; Tue, 05 Jun 2018 11:44:25 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1fQE89-0004lc-71
 for 31717 <at> debbugs.gnu.org; Tue, 05 Jun 2018 11:44:20 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46062)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1fQE89-0004lW-3T; Tue, 05 Jun 2018 11:44:17 -0400
Received: from [176.228.60.248] (port=3946 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1fQE87-0001jZ-7f; Tue, 05 Jun 2018 11:44:15 -0400
Date: Tue, 05 Jun 2018 18:44:26 +0300
Message-Id: <83muw99r1h.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Carlos Pita <carlosjosepita@HIDDEN>
In-reply-to: <CAELgYhfwvsyUrnhmi6zpHBqDc9u5F8D0OYKqt5gddYTEkpCu-g@HIDDEN>
 (message from Carlos Pita on Tue, 5 Jun 2018 12:19:55 -0300)
Subject: Re: bug#31717: 26.1; display-line-numbers-mode enlarges indicator
 without need
References: <87vaaym04z.fsf@HIDDEN>
 <CAELgYhfaQBWZELj+Mx6wpu2wOJDHU6WQkivOSOvtNP5P8RjtsA@HIDDEN>
 <83fu21b9dx.fsf@HIDDEN>
 <CAELgYhfwvsyUrnhmi6zpHBqDc9u5F8D0OYKqt5gddYTEkpCu-g@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 31717
Cc: 31717 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> From: Carlos Pita <carlosjosepita@HIDDEN>
> Date: Tue, 5 Jun 2018 12:19:55 -0300
> Cc: 31717 <at> debbugs.gnu.org
> 
> > If you don't want to "waste" one more column, you can use one of the
> > optional features, e.g., set display-line-numbers-width-start non-nil,
> > with or without display-line-numbers-grow-only non-nil.
> 
> I'm failing to see how this would prevent the "wasteful" behavior. Are
> you just saying that if I reserve all the space in advance I won't be
> seeing the widening happening since it have already happened up front?

AFAIU, it will reserve exactly the space needed by the number of lines
in the file.

> I understand all your points above, so I'm going to ask for a more
> modest alternative: the ability to suppress the left, right or both
> whitespaces in the indicator.

This produces ugly display, so I don't think it's a good idea.  If you
want to reserve less space for the line numbers, just customize the
line-number face to use a smaller font.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#31717; Package emacs. Full text available.

Message received at 31717 <at> debbugs.gnu.org:


Received: (at 31717) by debbugs.gnu.org; 5 Jun 2018 15:20:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 05 11:20:23 2018
Received: from localhost ([127.0.0.1]:35344 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fQDl1-0004YH-PB
	for submit <at> debbugs.gnu.org; Tue, 05 Jun 2018 11:20:23 -0400
Received: from mail-io0-f180.google.com ([209.85.223.180]:42579)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <carlosjosepita@HIDDEN>) id 1fQDkz-0004Y4-Uw
 for 31717 <at> debbugs.gnu.org; Tue, 05 Jun 2018 11:20:22 -0400
Received: by mail-io0-f180.google.com with SMTP id r24-v6so3791975ioh.9
 for <31717 <at> debbugs.gnu.org>; Tue, 05 Jun 2018 08:20:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=Ha1p/nTuWmOGkGHL+6RiYDPSAiDY4ClZE6Y1iC5mZNE=;
 b=KNE9xsv4Wv8kRTeg9Fnh9sbYPXpd/SaYixcOtBnfueJaB/a6qQQ5R6005Is7xVTzJ/
 llwZZFuaS2W/D5fFTOZW7J+A6nSYfXNeSk6NZTRXNdkVjJaNa4ApTe6mOIrMxBIc+eGs
 2KTYzeilslrEZxqReyrwJrYOhM9d6viiWTXtiNLAgyaKc5DaSkz0vx4d6TpGXhHfPzoG
 lda0EhSP72WHWGGI10mfAGCDLLhm1H2eiHFQCJ8HF6gpDjEx9Sy7XFMBePrFoOjeczRc
 0DnYl5RRCujhiC/ijl/5qB9p8DE2lDesWM4vlvo+QUDa/+gTaAH0r7ey2xmyCwghyEgY
 3vPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
 bh=Ha1p/nTuWmOGkGHL+6RiYDPSAiDY4ClZE6Y1iC5mZNE=;
 b=HS+HjvzIhKgcBe2hNfALdpHwLHvIkEzXE6O8TuTj7MMp0kkyxPFByRZydijcv9aRsF
 C40slOWUZRJ5WYmIR05raFEjtbWAk28Kgf21K6PLoVBOIQigsj0mjhdVVP3Ce5xoY6aN
 QvjBfHSZYieHRVg+dlBnwZ4c93T1WOeFcQaJdGpMU9vz6DWjLwtw22i24BN1vO129FQ7
 IArCFbOBUGorY0SR3kf5dQU5DPANMwFdSkUFTL93m9ijMqvG9OFiWo176Ky+C8v9vkRj
 63+PIBvB3jA5IZ4vmqQd+ZYLxP3SzTWQB/uGB+ONJZuZ/eBIOS54kgh8YK05Jf/Dt8Nl
 A1QA==
X-Gm-Message-State: ALKqPweRKqWQH3DfDM29KBIJqGEfgraYij0KvgWrRJjQlkUR6yMrMzv2
 W2DZWoOk9XMdq5WZeqrdLQERhCudbp6ZXqo94Aw=
X-Google-Smtp-Source: ADUXVKK0Olp08RY8cX15LEkOBfoKchMYgA79JAmnvCaMeSuVNffUyF9bkHVnKCgoON/dKCOh5xQ1H5uCxAivkL2khaY=
X-Received: by 2002:a6b:882a:: with SMTP id
 k42-v6mr25997402iod.137.1528212016366; 
 Tue, 05 Jun 2018 08:20:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:a98e:0:0:0:0:0 with HTTP;
 Tue, 5 Jun 2018 08:19:55 -0700 (PDT)
In-Reply-To: <83fu21b9dx.fsf@HIDDEN>
References: <87vaaym04z.fsf@HIDDEN>
 <CAELgYhfaQBWZELj+Mx6wpu2wOJDHU6WQkivOSOvtNP5P8RjtsA@HIDDEN>
 <83fu21b9dx.fsf@HIDDEN>
From: Carlos Pita <carlosjosepita@HIDDEN>
Date: Tue, 5 Jun 2018 12:19:55 -0300
Message-ID: <CAELgYhfwvsyUrnhmi6zpHBqDc9u5F8D0OYKqt5gddYTEkpCu-g@HIDDEN>
Subject: Re: bug#31717: 26.1; display-line-numbers-mode enlarges indicator
 without need
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 31717
Cc: 31717 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Thanks Eli for such an informative and detailed answer! It's worth
posting it somewhere more available, I will do something about that in
due time.

> If you don't want to "waste" one more column, you can use one of the
> optional features, e.g., set display-line-numbers-width-start non-nil,
> with or without display-line-numbers-grow-only non-nil.

I'm failing to see how this would prevent the "wasteful" behavior. Are
you just saying that if I reserve all the space in advance I won't be
seeing the widening happening since it have already happened up front?

I understand all your points above, so I'm going to ask for a more
modest alternative: the ability to suppress the left, right or both
whitespaces in the indicator. Do you think this is worth opening a new
issue or will it be rejected instantaneously/ignored for ever?

Again, thanks for taking the time to explain!




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#31717; Package emacs. Full text available.
Added tag(s) notabug. Request was from Eli Zaretskii <eliz@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 31717 <at> debbugs.gnu.org:


Received: (at 31717) by debbugs.gnu.org; 5 Jun 2018 14:23:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 05 10:23:00 2018
Received: from localhost ([127.0.0.1]:35232 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fQCrU-0005Wm-1k
	for submit <at> debbugs.gnu.org; Tue, 05 Jun 2018 10:23:00 -0400
Received: from eggs.gnu.org ([208.118.235.92]:50450)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1fQCrR-0005WZ-Rd
 for 31717 <at> debbugs.gnu.org; Tue, 05 Jun 2018 10:22:58 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1fQCrK-00054z-Lr
 for 31717 <at> debbugs.gnu.org; Tue, 05 Jun 2018 10:22:52 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44612)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1fQCrA-00050P-OZ; Tue, 05 Jun 2018 10:22:40 -0400
Received: from [176.228.60.248] (port=3814 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1fQCrA-0003QM-7B; Tue, 05 Jun 2018 10:22:40 -0400
Date: Tue, 05 Jun 2018 17:22:50 +0300
Message-Id: <83fu21b9dx.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Carlos Pita <carlosjosepita@HIDDEN>
In-reply-to: <CAELgYhfaQBWZELj+Mx6wpu2wOJDHU6WQkivOSOvtNP5P8RjtsA@HIDDEN>
 (message from Carlos Pita on Tue, 5 Jun 2018 00:30:10 -0300)
Subject: Re: bug#31717: 26.1;
 display-line-numbers-mode enlarges indicator without need
References: <87vaaym04z.fsf@HIDDEN>
 <CAELgYhfaQBWZELj+Mx6wpu2wOJDHU6WQkivOSOvtNP5P8RjtsA@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 31717
Cc: 31717 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

tags 31717 notabug
thanks

> From: Carlos Pita <carlosjosepita@HIDDEN>
> Date: Tue, 5 Jun 2018 00:30:10 -0300

(Sorry for a longish response, but you raise design and implementation
issues which cannot be explained without some non-trivial background.)

> When transitioning from line 69 to line 70 a new column is added to the
> left of the indicator as if there was a need to fit three digits despite
> that the file has less than 100 lines and despite that if it were larger
> line 100 would fall out of the window.

Right, this is the intended behavior, and there are good reasons for
it.  See below.

> It's as if the mode is anticipating an extra digit soon and playing
> conservative. I understand that there could be performance reasons for
> doing this (thus avoiding the need to compute the remaining lines in a
> window or file)

The main reason is performance, but it's not the only one.  You must
keep in mind that the code which produces line numbers is part of the
display engine -- it produces the line number as part of that line's
layout -- and that imposes very specific restrictions and conditions
on what we can do, how, and when.  I try to explain the issues below
in more detail, but the main point is that you simply _cannot_ think
about stuff done in redisplay as if it were some Lisp program running
off post-command-hook or somesuch, it's a very different runtime
environment with peculiar requirements.

> but:
> 
> 1. The mode is already adding two whitespaces around the line number
> indicator. Wasting one more char is on the verge of infuriating ;)

If you don't want to "waste" one more column, you can use one of the
optional features, e.g., set display-line-numbers-width-start non-nil,
with or without display-line-numbers-grow-only non-nil.

> 2. AFAICS computing the file size doesn't seem too demanding a task,
> neither the remaining lines in a window  (although the window could be
> resized).

Doing this as part of a redisplay cycle is precisely what made linum
mode so slow.  In a nutshell, it would require displaying each window
twice, because the exact number of lines in a window is known only
after it was completely redrawn (remember that Emacs supports
variable-size fonts and non-character display elements such as images,
which all affect the number of lines in a window).

As for computing the number of lines in a buffer, I guess you never
have to deal with very large buffers, if you think it's scalable.
With today's 64-bit architecture, the maximum buffer size supported by
Emacs is too huge to allow us to count lines all the time; plus, as I
explain below, the display code which produces line numbers is called
much more than you evidently assume.

> Also, when the mode is visual or relative this is happening too.

By default, visual and relative line numbers still display the
absolute line number for the current line, so we still need enough
space for that.  And the current line could be the last line of the
window.  (And if you think the fact that only the current line needs
this makes the life of the implementation easier, read on, and you
will understand why not.)

> In these cases, given that I assume you are assuming <= 69 is a safe
> guess, it will be *always* safe to limit the indicator width to that
> required by the current line.

As you later discovered, there's no 69 value anywhere in the code, the
space needed for the line-number display is estimated dynamically and
depends on the window size and the font size used by the window's
frame.  For a very large window, the switch could be much sooner than
line 69; for a very small window, it could be very close to 100.

> A little more experimentation with different windows sizes made me
> realize that the <70 hard and fast rule doesn't exist. Now I see the
> threshold indeed depends on the window size. But it is still too
> conservative, leading to premature enlargement of the line number
> space.

It _must_ be conservative, because it needs to decide on the space for
the line numbers _before_ it displays the first line of the window.

Here's some background information regarding the requirements imposed
by the display engine on the line-number implementation:

The Emacs display engine works by "screen lines".  (A screen line is a
single horizontal line of the display "canvas"; continuation lines
count as additional screen lines.)  The workhorse of the display
engine is a function that lays out a single screen line.  In some
cases Emacs invokes that function to redraw all the lines of a window,
one by one; in other cases, the function is invoked to produce only a
few screen lines, or even just one, when Emacs is able to decide up
front that none of the other screen lines need to change on display --
being able to do this is an important part of Emacs redisplay
optimizations.

In addition, Emacs needs to take text layout on display into
consideration in many situations that have little to do with actual
redisplay.  For example, vertical-motion (which is the basis of any
vertical cursor movement and scrolling commands) needs to determine
the character directly below or above the character at point,
something that obviously depends on the stuff displayed between point
and that other place, the faces involved, etc.  As another example,
consider a mouse click inside the window, where Emacs needs to know
the buffer position at the click coordinates.

For these reasons, the display routines that perform layout
calculations are used _a_lot_ in Emacs, and must (a) be very
efficient, and (b) produce consistent results no matter whether they
are called to redraw the entire window or just a small part thereof.
In particular, the functions that lay out a single screen line have no
idea about the context in which they were called -- they don't know
whether they are called as part of a complete window redisplay, or
just to draw a single screen line.  They must produce exactly the same
results regardless, and without depending on any such context.

I hope you are now beginning to understand why the feature works as it
does.  The code must calculate the space required for line-number
display before it displays the first line of a window, and the result
must be guaranteed to fit for all the lines in that window, because
otherwise some window line near the end might need more space, and you
will either have an ugly "jagged" display, or will need to abandon the
redisplay cycle and trigger another cycle -- which will be slow
(that's basically what linum.el does, and we already know it's slow).
How do we estimate the largest line number to be displayed in the
window in a way that is never too small?  Well, the display engine
keeps an estimation of the maximum number of screen lines in the
window, based on the fonts defined by the frame -- it needs to know
that because that defines the dimensions of the canvas used for
displaying the window.  So we simply reuse that estimation for this
purpose.  That estimation is always a conservative one, and it cannot
be any other way.  (Btw, it is much less conservative on TTY frames,
for obvious reasons, so there you will see much less "waste".)

> I suggest three optimizations in order of assumed (wild guessed)
> ascending difficulty:
> 
> 1. For relative/visual modes never reserve extra space.

Cannot be done, because when the space for line numbers is computed,
Emacs doesn't yet know what will be the current line, nor where in the
window it will be.  The current line, which is the line that displays
the cursor, is computed only near the end of the redisplay cycle of a
window.  And the code must use the same conservative estimate to be
able to display the largest line number possible.  If you don't need
to see the absolute line number in relative mode, customize
display-line-numbers-current-absolute to nil, and the "waste" will
indeed be no more.

> 2. If the lines in the file are < N never reserve extra space for >= N.

Can't be done by default, because counting lines in a very large
buffer will slow down redisplay and any command that uses display code
(see above).  It would also cause unpleasant redrawing and horizontal
movement of text when you add lines at the end of the buffer.

However, you can have this as an optional feature, if you customize
display-line-numbers-width-start to a non-nil value.

> 3. Take also into account the remaining window lines (I assume this is
> not as easy as it sounds).

Can't be done, because it would require a second redisplay cycle,
which will get us back to the same performance problem as we have in
linum.el.  I didn't write this feature just to have it work as slow as
linum.el, only in C ;-)

(Of course, if someone has clever ideas how to improve line-number
display, please speak up, but you should make yourself familiar with
the related code in the display engine first.)

I hope the above explains why we have the implementation we have.  All
in all, I find the price entirely reasonable, given the performance
gains (the default configuration works with line numbers almost as
fast as without them).  And we have a few customizable options to
optionally enable features which alleviate some of these issues, for
those who are willing to pay the price.

P.S.  Please make a point of keeping the full title of the bug in your
responses and followups, because removing the title and leaving just
the bug number makes it much harder to find all the messages that
pertain to the same bug, at least with Rmail.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#31717; Package emacs. Full text available.

Message received at 31717 <at> debbugs.gnu.org:


Received: (at 31717) by debbugs.gnu.org; 5 Jun 2018 03:30:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 04 23:30:39 2018
Received: from localhost ([127.0.0.1]:33835 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fQ2gA-0004tV-VB
	for submit <at> debbugs.gnu.org; Mon, 04 Jun 2018 23:30:39 -0400
Received: from mail-io0-f176.google.com ([209.85.223.176]:36966)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <carlosjosepita@HIDDEN>) id 1fQ2g9-0004tC-7O
 for 31717 <at> debbugs.gnu.org; Mon, 04 Jun 2018 23:30:37 -0400
Received: by mail-io0-f176.google.com with SMTP id s26-v6so1563611ioj.4
 for <31717 <at> debbugs.gnu.org>; Mon, 04 Jun 2018 20:30:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=2fE/jNNfkDiTJK4c0/NLg8sJk6VmNCZQCBLUTnukv68=;
 b=uSPjpcQjG0xkJqesvFb1hhKERIl+L79NnTIN+hOe7huxRUOWOBl6dbMJATjGaQmsHE
 JfPwR1vrFYkMDGEfyxqfmaz+EV/W2O6MMVuJIdivfLRrN9FkHAFx4ngBcMDZgxLlfAMm
 80Yk9yVDp8pjiPzIX5zun8fpHkfOECZVLE4BLGpRFxfVWoPe1yCKrCTL8o+InZ7UFhx0
 0WT7Fkr4FPvwUCCLWAKmsmvDVqprl5DXlwgen7GjQhM/joLSddMYT+NDg0rPa1+QiH4M
 fmqewX9LlPfwQpkxCnygkj0tamayHvQpjEOELCi3QeA5GNtoHrtK1iav1xvjRFvpUIfm
 JXFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=2fE/jNNfkDiTJK4c0/NLg8sJk6VmNCZQCBLUTnukv68=;
 b=dCkeVCUne/Dbp5jroydvq3Y7WJsSzAxbvjXJXju0iQ7QLINCQnfFzNDPMcSUC65Vn6
 vjHTolLW9ptclIm1dqqzVlfIFnqoiJB8i8hwekkFnKjkNQm9eWV//Waba/cGr7ZGj7bd
 U8CiZTxRcgrMPNAIlnlbp0pnLHN0FhHLU7zA8T8fYlwZMCHJDbqV73tFg+TSrI5IeI+J
 7kNz3FqRBK3e/g0MeQ6vRZ5AJ3okgh/IbiZh+u3+ZlHIVYVnpo8VG56p4gNHDnr42zZQ
 Ztrcl76K1N5sEGu7/q6GqNTrYljifakD7c/bx5qWMJ/+xi1+3pSyLmFUGJK0xsZfdAyq
 Rquw==
X-Gm-Message-State: ALKqPwcGQO2ca6YnFbaC9B0qAWJHqJqkezR4nsMsQhM4NXO7afzF8eEq
 oJubWUI3M+e/vaA9qRkvwWTuyz4NtOkRQz6nIxg=
X-Google-Smtp-Source: ADUXVKJD9VxPdfN/6DyppPlUYdWWLtvGJSDcYv7AMI72stg8q+4hLeKY1HMBptlf4pQJj0C1n2vKFhU04Sk0xPXNfaE=
X-Received: by 2002:a6b:2b10:: with SMTP id
 r16-v6mr23261077ior.204.1528169431457; 
 Mon, 04 Jun 2018 20:30:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:a98e:0:0:0:0:0 with HTTP;
 Mon, 4 Jun 2018 20:30:10 -0700 (PDT)
From: Carlos Pita <carlosjosepita@HIDDEN>
Date: Tue, 5 Jun 2018 00:30:10 -0300
Message-ID: <CAELgYhfaQBWZELj+Mx6wpu2wOJDHU6WQkivOSOvtNP5P8RjtsA@HIDDEN>
Subject: 
To: 31717 <at> debbugs.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  A little more experimentation with different windows sizes
 made me realize that the <70 hard and fast rule doesn't exist. Now I see
 the threshold indeed depends on the window size. But it is still too
 conservative, 
 leading to premature enlargement of the line number space. [...] 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
 trust [209.85.223.176 listed in list.dnswl.org]
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (carlosjosepita[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
 2.0 BLANK_SUBJECT          Subject is present but empty
X-Debbugs-Envelope-To: 31717
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

A little more experimentation with different windows sizes made me
realize that the <70 hard and fast rule doesn't exist. Now I see the
threshold indeed depends on the window size. But it is still too
conservative, leading to premature enlargement of the line number
space.

I suggest three optimizations in order of assumed (wild guessed)
ascending difficulty:

1. For relative/visual modes never reserve extra space.
2. If the lines in the file are < N never reserve extra space for >= N.
3. Take also into account the remaining window lines (I assume this is
not as easy as it sounds).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#31717; Package emacs. Full text available.

Message received at 31717 <at> debbugs.gnu.org:


Received: (at 31717) by debbugs.gnu.org; 5 Jun 2018 02:55:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 04 22:55:12 2018
Received: from localhost ([127.0.0.1]:33827 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fQ27s-00045N-4j
	for submit <at> debbugs.gnu.org; Mon, 04 Jun 2018 22:55:12 -0400
Received: from mail-io0-f170.google.com ([209.85.223.170]:42777)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <carlosjosepita@HIDDEN>) id 1fQ27q-00045A-Gd
 for 31717 <at> debbugs.gnu.org; Mon, 04 Jun 2018 22:55:10 -0400
Received: by mail-io0-f170.google.com with SMTP id r24-v6so1474443ioh.9
 for <31717 <at> debbugs.gnu.org>; Mon, 04 Jun 2018 19:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=RsAZdqeIb44JAAtxNvH/L3rvCAa35Lm+6GjhrQZ6Huk=;
 b=Xp8SdIoEb1LLn1oNZ1iyG1LDho3lM64gZjaKwRvPXXJz4OLmCb34Z1X6DfZLDOPgDV
 F6BOT+pWdsqgREYJnNHFkTNi6EWFUECpRymDJM2WDB6YJpWgIV83rDbY7YMoK3L4Jw1Y
 JBJtzULeL63xaHMxE4ETpyztzK54Up4cq5Vytf/gDuiNwqVZf9XAcWRkEndOXLJoOT0m
 1B5se9oC55r2/42XRMcwn3nO9R35S8jjZWlflh/2FXwnYZ20RmF2g+zC9H//RHYn5ZGV
 qpC9iX9vfl13fRTxVyv9Qb2q7NY599YWJZO3G87e0ptBlobZla+yIYOIyFHHQwcUW3tt
 vc1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=RsAZdqeIb44JAAtxNvH/L3rvCAa35Lm+6GjhrQZ6Huk=;
 b=ELwVk3hCiqjc8U9FaWWOoMuQzuJ+oTpfDOw9NAYsHoKWWs0ey3LWzBhsaRWEYg9GNG
 uDG4x0t9QpnXVqkE4FJlCvYbWiwmOdAPoYQB6a7V3HSO+1Y1EH8qvvLMR4f+i5IFj/dc
 El7Q1iMNseOs2y2C4mr6aB8a30+CxvFhKfbCI++g5QcfH/17fnlk9m5v62FOmPdVNC3A
 9vFsUJOgsRQMlSDKQ4+t4NfVBrvlhYnTvDMzT9jteQVzBcM2oDYDsD/TpDltH/UsiQ0Q
 TXRSnQ4ye6E8RW/FfJK52QxVpU16uFrYBE9yPoHgdyM1kBE8y+s2e+AsiHD0jcfkyVBQ
 eVGg==
X-Gm-Message-State: APt69E1je/7yj/hRXL72hPoQ2lV9pQLy37IDQrg9bEnQY/BHq63Ykfgj
 OIkOeB0LgQ9p7Esr+D98dk5Lo3GLaEmpiYGEwt8=
X-Google-Smtp-Source: ADUXVKKbjF7BlsNBoxo9rv651S5h83Qt4T45tq5jUU4fHNc187jgy1J/h+J4hfp0HtN04O3Yx2u7ur33KRY3Ob26Gv8=
X-Received: by 2002:a6b:bfc1:: with SMTP id
 p184-v6mr24421009iof.80.1528167304514; 
 Mon, 04 Jun 2018 19:55:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:a98e:0:0:0:0:0 with HTTP;
 Mon, 4 Jun 2018 19:54:44 -0700 (PDT)
From: Carlos Pita <carlosjosepita@HIDDEN>
Date: Mon, 4 Jun 2018 23:54:44 -0300
Message-ID: <CAELgYhfW6F5cZzA9z4rrNKtSM50i+NkZ1r7p9TT0d-R+FFyYnw@HIDDEN>
Subject: 
To: 31717 <at> debbugs.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Also, when the mode is visual or relative this is happening
 too. In these cases, given that I assume you are assuming <= 69 is a safe
 guess, it will be *always* safe to limit the indicator width to that required
 by the current line. [...] 
 Content analysis details:   (1.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
 trust [209.85.223.170 listed in list.dnswl.org]
 -0.8 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [209.85.223.170 listed in wl.mailspike.net]
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (carlosjosepita[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid
 2.0 BLANK_SUBJECT          Subject is present but empty
X-Debbugs-Envelope-To: 31717
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

Also, when the mode is visual or relative this is happening too.

In these cases, given that I assume you are assuming <= 69 is a safe
guess, it will be *always* safe to limit the indicator width to that
required by the current line.

So this would be an easy optimization: in visual and relative modes
never anticipate an additional digit.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#31717; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 5 Jun 2018 02:35:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 04 22:35:26 2018
Received: from localhost ([127.0.0.1]:33809 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1fQ1ok-0003dH-J5
	for submit <at> debbugs.gnu.org; Mon, 04 Jun 2018 22:35:26 -0400
Received: from eggs.gnu.org ([208.118.235.92]:42144)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <carlosjosepita@HIDDEN>) id 1fQ1oi-0003d4-V6
 for submit <at> debbugs.gnu.org; Mon, 04 Jun 2018 22:35:25 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <carlosjosepita@HIDDEN>) id 1fQ1ob-0003av-GL
 for submit <at> debbugs.gnu.org; Mon, 04 Jun 2018 22:35:19 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
 T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:35129)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <carlosjosepita@HIDDEN>)
 id 1fQ1ob-0003ar-Ci
 for submit <at> debbugs.gnu.org; Mon, 04 Jun 2018 22:35:17 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33095)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <carlosjosepita@HIDDEN>) id 1fQ1oX-0001ne-W2
 for bug-gnu-emacs@HIDDEN; Mon, 04 Jun 2018 22:35:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <carlosjosepita@HIDDEN>) id 1fQ1oQ-0003Wf-Ti
 for bug-gnu-emacs@HIDDEN; Mon, 04 Jun 2018 22:35:12 -0400
Received: from mail-qt0-x231.google.com ([2607:f8b0:400d:c0d::231]:37196)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.71) (envelope-from <carlosjosepita@HIDDEN>)
 id 1fQ1oQ-0003WV-Nv
 for bug-gnu-emacs@HIDDEN; Mon, 04 Jun 2018 22:35:06 -0400
Received: by mail-qt0-x231.google.com with SMTP id q13-v6so893371qtp.4
 for <bug-gnu-emacs@HIDDEN>; Mon, 04 Jun 2018 19:35:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:subject:date:message-id:mime-version;
 bh=ZuZjTcSFP33yyUBZ1bwun90t7YRc1+no4WQmkmYRWTo=;
 b=FDquo5NJ8MuLmnDz+LnFoS0P/6QoxpRcDQRk8QVWbzt00XYYjbx98uDfC92IfPWnF9
 4vzHxOQUcZpheQqSX3Ma3VA7VspgFZaLrF0dWJJdGjiEILWdCK4AzSqITa3SNZKbXe33
 p2+monwjqN19GioU4Ek+lietA/9/c0KAnTk6OpV5CXpSKx71dQU0kJ37OBnTCN5dsoD1
 qHzXtiUTuDTft/q4tGqBKlrz4F2YB1DS8nQjEWv7HkWUOtOhkF7pqNkDMxGEYOYMYEQv
 fRAr6HmmxzHTpMWBQ68lOiVGfju32Oh7Zj2w2fRsB76ZdomLtf4+DlvyOtjds57s3cC7
 bl6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:subject:date:message-id:mime-version;
 bh=ZuZjTcSFP33yyUBZ1bwun90t7YRc1+no4WQmkmYRWTo=;
 b=g0384+BvRaJV4oyy4r05hzLkYBRZRbr3rh2GCkTPIgNbEezYnFRAb5fte7W4VlbItP
 4uJn613Dm9SLfzYWdp1FXZm0XdnJqZX/Rp1qPoe8PGdCxW/plx3I+0cb59izZN2Za9BT
 M0pZoVstkDTaHvVtEVxVentnjI7NHGS+lNWL2V9zgEZ8sF/qpMMsRCXjC5Ox6Q0QIYDG
 af4eGYs/L84UcA50fzNV5R8RcKHhLEZdFNhtmjsNCRnZz9vYhsUk9xFwddL2LikP2xWd
 qPKYM0ZJVP/6ckMlRj1h7ZK8jD4bvPofSR/z0fcqotrFrpJdmkFLWRV0jfyG9mIA8dIe
 8zSA==
X-Gm-Message-State: APt69E1m7MeBwU76gyCXpk3InTAqGL7l1z08QsJB0TthQhMwQTQfuxZx
 pMUUUWqJjIqQEp4f+ApHnlkXAQ==
X-Google-Smtp-Source: ADUXVKKE7FUDXr6UQ1lI7NcASv8cCoOF1LcRw8RyeUzpb7l8B5fDs0VLBLARC99hWS4KUwUOEc0OvA==
X-Received: by 2002:ac8:3338:: with SMTP id
 t53-v6mr22069928qta.312.1528166105791; 
 Mon, 04 Jun 2018 19:35:05 -0700 (PDT)
Received: from carlos ([190.2.33.33])
 by smtp.gmail.com with ESMTPSA id t6-v6sm14839107qtn.86.2018.06.04.19.35.04
 for <bug-gnu-emacs@HIDDEN>
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Mon, 04 Jun 2018 19:35:05 -0700 (PDT)
From: Carlos Pita <carlosjosepita@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 26.1; display-line-numbers-mode enlarges indicator without need
Date: Mon, 04 Jun 2018 23:34:52 -0300
Message-ID: <87vaaym04z.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
 recognized.
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.0 (----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)


When transitioning from line 69 to line 70 a new column is added to the
left of the indicator as if there was a need to fit three digits despite
that the file has less than 100 lines and despite that if it were larger
line 100 would fall out of the window.

I have tested the transition from 969 to 970 and it shows the same
effect.

It's as if the mode is anticipating an extra digit soon and playing
conservative. I understand that there could be performance reasons for
doing this (thus avoiding the need to compute the remaining lines in a
window or file) but:

1. The mode is already adding two whitespaces around the line number
indicator. Wasting one more char is on the verge of infuriating ;)

2. AFAICS computing the file size doesn't seem too demanding a task,
neither the remaining lines in a window  (although the window could be
resized).

---

In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2018-05-29 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description:	Manjaro Linux

Recent messages:
Quit [2 times]
C-h C-g is undefined
nil
Quit
Display-Line-Numbers mode disabled in current buffer
x is undefined
Display-Line-Numbers mode enabled in current buffer
0 (#o0, #x0, ?\C-@)
scroll-down-command: Beginning of buffer [3 times]
Making completion list...

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 MODULES THREADS LIBSYSTEMD LCMS2

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  display-line-numbers-mode: t
  diff-auto-refine-mode: t
  pyvenv-mode: t
  shell-dirtrack-mode: t
  ido-everywhere: t
  winner-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils pp cl-print jka-compr vc-git display-line-numbers
doom-tomorrow-night-theme doom-themes doom-themes-common cl-extra
yasnippet elec-pair highlight-indentation flymake-proc flymake warnings
company edmacro kmacro pcase help-fns radix-tree help-mode elpy
find-file-in-project ivy delsel ivy-overlay ffap thingatpt diff-mode
easy-mmode elpy-shell pyvenv esh-var esh-io esh-cmd esh-opt esh-ext
esh-proc esh-arg esh-groups eshell esh-module esh-mode esh-util
elpy-profile elpy-django s elpy-refactor subr-x python tramp-sh tramp
tramp-compat tramp-loaddefs trampver ucs-normalize shell pcomplete
parse-time format-spec advice json map ido grep compile comint
ansi-color files-x etags xref project cus-edit cus-start cus-load
wid-edit winner ring windmove finder-inf info package easymenu
epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 395972 45995)
 (symbols 48 33197 1)
 (miscs 40 181 236)
 (strings 32 77765 6307)
 (string-bytes 1 2252569)
 (vectors 16 53016)
 (vector-slots 8 923948 18050)
 (floats 8 186 268)
 (intervals 56 4758 0)
 (buffers 992 16))




Acknowledgement sent to Carlos Pita <carlosjosepita@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#31717; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Tue, 5 Jun 2018 15:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.