[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28533: 26.0.60; Native line numbers move with show-paren-mode enable
bug#28533: 26.0.60; Native line numbers move with show-paren-mode enabled
Sat, 23 Sep 2017 09:49:03 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
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.
But why in private email?
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
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.
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