Re: Native line numbers, final testing

[Eli Zaretskii]

> 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.

> 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.

> >> > 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?

Yes.  But I think we are talking past each other, see below.

> 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.)

> >> 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?

> > 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 believe that the C-n/C-p issue should at least be a blocker for 26.1.

We should be well past this long before we consider what blocks 26.1.