Re: Native line numbers, final testing

[Alex <agrambot@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 01 Jul 2017 15:00:50 -0600
>> 
>> It's not intuitive to me why this occurs between lines with the same
>> display line number width. If vertical-motion uses the same heuristic as
>> display of line numbers, then why is the column changing between lines
>> even when the width of line numbers isn't?
>
> 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.

>> Why is it necessary for line numbers to actually affect the vertical
>> position of characters in the buffer?
>
> Because vertical-motion does its column calculation in pixels, C-n/C-p
> need to adjust the calculations due to the pixels occupied by line
> numbers.
>
>> I suppose it's a bit late to be asking this question, but the
>> approach from an outside view feels odd. I don't know what the
>> options were, but it's odd that line numbers aren't in their own
>> special area like in (n)linum. Does the display engine not work well
>> with margins?
>
> 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.

Can there not be multiple margins on one side? 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.

If not, why? That seems like a clear win to me, if it's possible. As a
bonus, it would allow for users to customize the positions of elements
in the margins (and fringes, hopefully).