Re: Native line numbers, final testing

[Alex]

Eli Zaretskii <address@hidden> writes:

>> From: Alex <address@hidden>
>> Cc: address@hidden
>> Date: Sun, 02 Jul 2017 23:06:29 -0600
>> 
>> > I think I fixed that now.
>> 
>> The issue is a bit harder to encounter now, but it appears to still be
>> present. In xdisp.c:
>> 
>> M-g c 2970 RET
>> C-u 16 C-n
>> 
>> Then hit C-n a few times to reach line 87. The cursor will now be on
>> column 26 instead of column 27.
>> 
>> You can also test this by holding C-n or C-p and noticing the goal
>> column changing. This also affects C-v and M-v with
>> scroll-preserve-screen-position set to 'always.
>
> No, that's an entirely different issue, and arguably not a bug at all.
> In line-move-visual mode, C-n/C-p (and vertical-motion they call under
> the hood) keep the horizontal screen coordinate as much as they
> possibly can, and this is what happens here.
>
> You can see the same "bug" with this simple recipe:
>
>   emacs -Q
>   M-: (add-text-properties 72 73 '(line-prefix "12345")) RET
>   C-u 10 M-g c
>   C-=
>   C-n
>   C-=
>
> The last command will say "column=4" although you started with
> column=9.
>
> Maybe with C-n/C-p people will expect what you expected in the case of
> line numbers (but I'd like to hear more opinions before I'm convinced
> to change the code to do that),

I've never heard of line-prefix before this discussion, so I don't know
what the expected behaviour of it is/should be. However, I don't believe
the width of the line numbers should have any bearing on the column
position of a particular character in the buffer. Indeed, C-x = at the
beginning of a line with display-line-numbers correctly shows
"column=0". So I don't see the link between your recipe and mine.

I highly doubt many, if anyone else, expect line numbers to behave like
this.

> but you will have a much harder time
> convincing me to make a change in how scroll-preserve-screen-position
> behaves in this case.

Perhaps this one makes sense, since it is preserving screen position
rather than column position. I'll wait and see if this part bothers me
in the future.

>> > And note that displaying the numbers in the margin would not have
>> > solved the issue, since the width of the margins would still be
>> > estimated by the same heuristics.
>> 
>> So there's no reliable way to get the x-coordinate of the end of the
>> left margin/fringe?
>
> Of course there is: call posn-at-point and its ilk.
>
> The problem is to know that x coordinate _before_ the margins actually
> change their width.  That is the problem to be solved in this case.

I don't understand. If the x-coordinate can be calculated at the start
of vertical-motion, then isn't that the x-coordinate before the margins
change their width?

As a thought for the current problem, could you adjust the position
after vertical-motion is called if it turns out that the
line-number-width/margin-size changed?

>> Why don't these issues affect nlinum, since it sets
>> the width dynamically?
>
> Because nlinum and similar modes change the width of the margin
> _after_ C-n already moved point.  So C-n does its thing with the
> margin still at its old width, and doesn't need to deal with the width
> changing under its feet.

Didn't you write before (when talking about 'visual) that line number
calculation/display was done after the point is moved? In that case, how
is display-line-numbers different to what you just described (outside of
not using the margin)?

>> On this note, I'd like to again ask for dynamic growing of the width,
>> but not shrinking. That should also help towards avoiding this problem
>> in growing buffers.
>> 
>> I've edited and attached my previous proof of concept, but it uses
>> Fmake_local_variable, which doesn't look like it's used a lot in the C
>> side of Emacs. Is there a better way to make buffer local internal
>> variables?
>
> I don't think this should be done in C.  I can provide a function to
> obtain the current width of the line-number display, and then a Lisp
> program, called from some suitable hook, could notice when the value
> becomes larger, and set display-line-number-width to that same value.
> Would that be satisfactory?

If the performance and convenience is about the same, then I suppose it
doesn't matter where it's implemented. What would be a suitable hook? I
see a pre-redisplay-functions, but not a post-redisplay-functions. Or
would you provide a specific display-line-number hook?

> P.S. Btw, I think these are all minor issues that shouldn't prevent
> landing the feature on master.

I believe that the C-n/C-p issue should at least be a blocker for 26.1.