Re: Native line numbers, final testing

[Alex]

Eli Zaretskii <address@hidden> writes:

>> From: Alex <address@hidden>
>> Cc: address@hidden
>> Date: Fri, 30 Jun 2017 13:06:27 -0600
>>
>> I forgot that just before testing relative line numbers, I set
>> `display-line-number-width' to a non-nil value. For immediate results,
>> try setting it to 0 and hit C-n/C-p a few times.
>
> Ah, okay.  Thanks, should be fixed now.

Thanks, it appears to be fixed.

I noticed another bug. With `display-line-numbers' set to t or 'relative
in xdisp.c:

M-g c 2970 RET
C-n

Notice that C-n moved back one column. This does not happen with
'visual, nor does it happen when the window is sufficiently small. This
is in emacs -Q, and only happens with non-nil line-move-visual.

>> P.S. I noticed that with display-line-numbers set to 'visual, goto-line
>> is much slower compared to 'relative. Is this expected?
>
> Yes.  The initial naïve implementation was unbearably slow, but I was
> lucky to find a shortcut.  It is still sometimes slow, and a few
> redisplay optimizations are disabled with this mode, because moving
> point vertically needs to redisplay the entire window, since the line
> numbers change.  If someone has ideas for speeding it up, I'm all
> ears.

I'm not planning to use 'visual, and I of course don't claim to know
anything about this, but I'm curious as to why it works like this.
goto-line in either style always goes to the same absolute line number,
right? Does the line number display calculation occur after the point is
already moved to this line? If so, then doesn't the display engine just
need to calculate the visual line numbers around this point? If so, then
why does a large jump like M-g g 25000 take so much longer comparatively
than M-g g 1000? If these assumptions are wrong (they likely are), why
are they wrong?