bug#28533: 26.0.60; Native line numbers move with show-paren-mode enabled

[Romanos Skiadas <rom.skiad@gmail.com>]

> But why in private email?
Because I keep accidentally pressing C-r on thunderbird instead of C-R. 
This is the third time this week I've done this that I know of, sorry. 
Thanks for taking the time to explain all these things to me. Feel free 
to close the bug now if you haven't already.
>>>> If you think it is a WONTFIX kind of deal, I'm ok with closing it. As
>>>> far as I can tell the customizations you suggested are not somewhere in
>>>> the docs. Should they added in NEWS and in any other relevant documentation?
>>> Not sure what you mean: the variables I mentioned are AFAIK documented
>>> in the Emacs manual.
>> They are documented, but using them in a way to circumvent this problem
>> is not. I might be wrong, so if that is the case let me know. A mention
>> in the display-numbers-mode docstring along the lines of "if you fold
>> lines in the buffer set such and such variable to X value" would be useful.
> I added that now to the Emacs manual.
Thanks, I saw that.
>
>>> Org mode has special needs when non-relative line numbers are
>>> displayed, and the solution should IMO be in Org, not in Emacs core,
>> There are other ways to hide line numbers, such as
>> set-selective-display, which can be used in any mode. There other are
>> minor modes that do that too like evil & origami.
> they should all adapt, if their users use line-number display a lot.
>
>>> because solving that in core would mean significant run-time penalties
>> How significant?
> Very significant: they would require doing each redisplay cycle twice.
>
> You must understand the problem to see the difficulty: the display
> engine calculates the space needed for line-number display just once,
> at the beginning, when it is about to display the first line, and then
> reuses the result of that calculation for all the subsequent lines.
> It estimates the maximum number of lines that can be visible in the
> window to do that, but it cannot know in advance how many lines will
> be hidden from display without displaying them first.  So it would
> need to display twice.  This is what linum-mode did, and that's the
> reason why it was so slow.  I don't think it's right to bring that
> slowdown back, when reasonable solutions exist on the Lisp level.
I see. Thanks for explaining.
> , that is good.
>
>> on the other hand, solving it in core means that every
>> mode that folds buffers won't have to solve it themselves or ask their
>> users to solve it.
> Yes, and why is that a problem?  Many modes already have
> accommodations for popular minor modes, including linum-mode.  Why
> cannot they accommodate this new feature as well?
>
> Solving everything in the core has a price, and good engineering
> doesn't punish everyone on behalf of the needs of a few.  Let those
> few pay the price in adapting.
Fair point.
>
>> Also, on the point of what Emacs calculates as the minimum width, I
>> checked with other editors (gedit, the one that starts with V and ends
>> with IM) and they calculate the size of the width to be the one of the
>> last line in their buffers.
> That's what display-line-numbers-width-start does in Emacs.  But it
> does that once, when the buffer is first created.  Counting all the
> lines in the buffer upon each redisplay cycle would be prohibitively
> slow in large buffers, so Emacs doesn't do that.  However, if you
> customize display-line-numbers-grow-only as well, you will have the
> best of all worlds.
>
>> So if the last line is 1234 the width is 4 regardless of where you
>> are in the buffer. The problem wouldn't show up if Emacs calculated
>> the width this way, would it? This way of calculating things has the
>> added benefit that if you scroll up the buffer when line ~100 is at
>> the bottom the text doesn't suddenly shift right by one, which I
>> find really annoying.
> If this annoys you, you should set display-line-numbers-grow-only
> non-nil.
Ah, thanks.