Re: Native line numbers, final testing

[Alex]

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? I believe I understand now, though
I still disagree that line numbers should behave similarly.

It appears that both nlinum and display-line-numbers contradict the 2nd
sentence of the documentation for line-move-visual. When the line number
width in nlinum increases, everything including the cursor is shifted
over. So if C-n triggers this change, then one could consider this to be
wrong behaviour.

In display-line-numbers, then C-n and C-p both may not preserve the
current horizontal screen position even when the line number width does
not (noticeably) change. Here, the horizontal screen position of the
cursor is moved by 1 character, but in contrast to the nlinum case, the
rest of the buffer contents remain horizontally stationary.

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.

>> I highly doubt many, if anyone else, expect line numbers to behave like
>> this.
>
> It's quite possible.  I just want to hear that before I write the
> code.  Since I probably won't use line numbers (except for debugging
> problems they cause ;-), I don't think my judgment is good enough
> here.

I think a reasonable default is to behave similarly to the previous line
number implementations where it makes sense, and to change it if users
tend to dislike it. I suppose the contention here may be "where it makes
sense". I think it makes sense for the basic navigation commands to
behave similarly between the different implementations.

>> 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?
>
> Sure.  I already write code to do that, I just stashed it waiting to
> see what this discussion concludes.  (And it isn't enough to make the
> correction inside vertical-motion: temporary-goal-column also needs to
> be adjusted.)

It's good to know that there's a working solution. I hope it will land
in Emacs.

>> >> 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)?
>
> I think I lost the focus of this discussion, so I'm not sure anymore
> I'm answering your questions correctly.  What is it that you are
> getting at with these questions?

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.

>> > 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.
>
> pre-redisplay-functions should be OK, but I think even
> pre-command-hook is fine.  You really want to set this before
> redisplay runs, because after it runs it might be too late.
>
>> would you provide a specific display-line-number hook?
>
> I don't see why we would want such a hook, and what would it do and
> how.

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. A
hook called in the same area that it->lnum_width is changed would be the
best for that, though perhaps that's going overboard.

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.