Re: Native line numbers, final testing

[Eli Zaretskii]

> From: Alex <address@hidden>
> Cc: address@hidden
> Date: Thu, 06 Jul 2017 20:46:42 -0600
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> From: Alex <address@hidden>
> >> Cc: address@hidden
> >> Date: Tue, 04 Jul 2017 13:36:03 -0600
> >> 
> >> 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.
> >
> > "C-x =" just counts characters.  Try "M-: (posn-at-point) RET" for
> > more insight.
> 
> OK, so C-n/C-p currently try to preserve the column calculated by either
> posn-col-row or posn-actual-col-row?

More accurately, C-n/C-p try to preserve the horizontal coordinate
(which can be expressed either in pixels or in canonical column
units), and posn-col-row calculates and returns the same coordinates.

> If one has to choose between these two behaviours, then I believe the
> former is significantly more user-friendly. It is much easier to reason
> about, and it does not change the horizontal cursor position relative to
> buffer contents.

OK.

> Sorry, I think we both lost focus a bit since there's a few different
> topics in this thread. Here, I believe we were talking about line
> numbers in the margin, and if the property of being in the margin by
> itself would be able to avoid this issue. I was under the assumption
> that it would be, but assuming strict compliance to the documentation of
> line-move-visual, then I think I get now why it wouldn't.

Actually, I think it would be easier, because x coordinates are
counted from the text-area edge, so they are unaffected by the
margins.

But this fact alone is not enough to invalidate the design that
doesn't use the margin for line numbers.  A few complications like the
one we are talking about can always be solved by some support code,
they are not obstacles that cannot be negotiated.

> I figured it would be best to change display-line-number-width as soon
> as possible, and for the check to be made as infrequent as possible.

Line numbers are calculated every redisplay cycle (for those lines
that need to be redrawn), and a redisplay cycle always follows a
command, so the frequency is not affected by using the hooks I
proposed.

> pre-command-hook definitely sounds better than pre-redisplay-functions,
> but it would be nice if the check didn't have to be made every time a
> command is issued. Although I suppose if the width accessor is a fast
> constant lookup, then it doesn't really matter.

It cannot be an accessor to a value that is already stored (because it
currently isn't stored anywhere once redisplay finishes), but it
should be fast enough nonetheless.  And if it turns out it isn't, we
can always speed it up.