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.
, 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.
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.