Re: Native line numbers, final testing

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex <agrambot@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 02 Jul 2017 23:06:29 -0600
> 
> > I think I fixed that now.
> 
> The issue is a bit harder to encounter now, but it appears to still be
> present. In xdisp.c:
> 
> M-g c 2970 RET
> C-u 16 C-n
> 
> Then hit C-n a few times to reach line 87. The cursor will now be on
> column 26 instead of column 27.
> 
> You can also test this by holding C-n or C-p and noticing the goal
> column changing. This also affects C-v and M-v with
> scroll-preserve-screen-position set to 'always.

No, that's an entirely different issue, and arguably not a bug at all.
In line-move-visual mode, C-n/C-p (and vertical-motion they call under
the hood) keep the horizontal screen coordinate as much as they
possibly can, and this is what happens here.

You can see the same "bug" with this simple recipe:

  emacs -Q
  M-: (add-text-properties 72 73 '(line-prefix "12345")) RET
  C-u 10 M-g c
  C-=
  C-n
  C-=

The last command will say "column=4" although you started with
column=9.

Maybe with C-n/C-p people will expect what you expected in the case of
line numbers (but I'd like to hear more opinions before I'm convinced
to change the code to do that), but you will have a much harder time
convincing me to make a change in how scroll-preserve-screen-position
behaves in this case.

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

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

> On this note, I'd like to again ask for dynamic growing of the width,
> but not shrinking. That should also help towards avoiding this problem
> in growing buffers.
> 
> I've edited and attached my previous proof of concept, but it uses
> Fmake_local_variable, which doesn't look like it's used a lot in the C
> side of Emacs. Is there a better way to make buffer local internal
> variables?

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?

P.S. Btw, I think these are all minor issues that shouldn't prevent
landing the feature on master.