Re: Native display of line numbers

[Eli Zaretskii <eliz@gnu.org>]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Sun, 18 Jun 2017 23:54:38 +0700
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > But I'm not sure I understand the motivation: is it due to the
> > background issues with the margins?  If so, fixing that might be much
> > easier.
> 
> The base motivation is to have an intuitive ordering of out-of-buffer
> adornments. Out of the box in Emacs, there are:
> 
> * line numbers
> * line wrap indicators
> * horizontal scrolling indicators
> * debugging overlay arrows
> 
> Some IDEs also display in their gutters:
> 
> * change bars indicating modifications since the last commit (in
> Emacs, see Git-Gutter)
> * in-buffer bookmark indicators (functionality of bm.el)
> * folding indicators and controls (functionality of outline-minor-mode)
> * static analysis warnings (flycheck)
> 
> Some of these attract to the buffer text more strongly than others.

Yes, but why is that a problem?  And if some combinations are really
too much, then are those combinations really that frequent that they
should be source of a worry?  And if they are, how come this wasn't an
issue until now?

>     « sit amet, consectetur wgah’nagl fhtagn.
> 
> So far, in all cases, a scrolling indicator implies some text is
> elided at this point.
> 
> Now we enable line numbers. As is:
> 
>     « 42  amet, consectetur wgah’nagl fhtagn.
> 
> If the elided text were inserted at the position of the indicator, the
> line number would end up in the middle of the line. Compare:
> 
>     42 «t amet, consectetur wgah’nagl fhtagn.

OK, and what's your point?  That the line number display is not ideal?
I agree, but I think the alternatives are much worse.  E.g., switching
the order can only work on TTY frames and when the fringes are
disabled, so it cannot be done by default, or we will have
inconsistent behavior.  I'm sure people who like line numbers will get
used to the arrangement of indicators soon enough; I did.  Especially
since long lines are rare in source code buffers, at least IME.

> If the margin background issue were fixed but line numbers remained
> closely tied to the buffer, I would probably continue using the now
> deprecated linum-mode, because this configuration gives me the
> intuitive ordering.

Experience shows that using the margins for such pervasive modes is
trouble in itself, because there are modes which want to use the
margins for their own purposes.  We still don't have a satisfactory
solution for those problems.  Displaying the numbers in the text area
solves them by simply keeping its hands off the margins.  I think the
gains here outweigh the minor disadvantages by a large margin (pun
intended), so I'd rather pay those small "fines" to have a cleaner
solution for margin usage, let alone a much faster redisplay (have you
tried relative-line-numbers-mode in windows under Follow Mode?).