Re: Native line numbers, final testing

[Eli Zaretskii]

> From: Alex <address@hidden>
> Cc: address@hidden
> Date: Sat, 01 Jul 2017 23:16:11 -0600
> 
> > Because vertical-motion thinks the display uses N+1 columns whereas it
> > actually uses only N.
> >
> >> Is it because it's using the heuristic with different inputs?
> >
> > Yes.  The important input is the actual window-start point.
> >
> >> If so, can't they be modified to achieve the same results as the
> >> display of line numbers?
> >
> > I couldn't (yet) find a way of doing that.
> 
> That's unfortunate; hopefully this can be fixed.

I think I fixed that now.

> > I firmly believe that line numbers should not be displayed on the
> > margins, because that produces problems for packages that want to
> > display stuff there.
> 
> That seems to me to be an extensibility problem rather than line numbers
> not belonging in the margins. Without fixing that problem, then there
> will still be problems when multiple packages attempt to use the margins
> simultaneously.

That's correct, but since coexistence in the margin is problematic,
core features, especially popular ones, should not use the margins, so
as not to exacerbate the problems.

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.

> Can there not be multiple margins on one side?

No, not without a thorough redesign and rewrite of the display code.
The fact that there's at most one margin on either side of the text
area is hard-coded in many places.

> That way, line numbers can have its own special area, and there will
> be a clear x-coordinate for vertical-motion to start from, avoiding
> a whole class of errors that you've had to deal with so far.

See above: these problems won't be solved by going to the margin.  The
only way to solve them is to have a fixed width for line numbers,
something that can be done, if desired, by suitable setting of
display-line-number-width.