Re: Native display of line numbers

[Eli Zaretskii]

> From: Yuri Khan <address@hidden>
> Date: Mon, 19 Jun 2017 12:32:19 +0700
> Cc: Emacs developers <address@hidden>
> 
> How much is too much is subjective.

Fair enough.

> > 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,
> 
> I do not understand this limitation. Could you please elaborate?

Sure.  The basic restriction (well, unless the geometry of the display
canvas is redesigned) is that what is collectively called "display
elements" -- character glyphs, images, stretches of whitespace,
xwidgets, etc. -- can appear in one of 3 areas of the display: the
left margin, text area, and the right margin.  The order of these 3
areas is fixed, left to right (although one or both of the margins
could be empty).  Each one of the 3 areas is contiguous, so e.g. you
cannot place the fringe in the middle of the text area, as that will
disrupt layout calculations.

The line numbers in my implementation are in the text area, before the
actual line.  On TTY frames, the left-truncation indicator is also in
the text area before the actual line.  It is injected there by the
display engine in a way that is very similar to my implementation of
the line numbers.  So on TTY frames, I could in principle insert the
line number before the truncation indicator.  But that cannot be done
on GUI frames, because the indicator is on the fringe, and cannot be
moved to be to the right of the line numbers, as long as we want the
line numbers to be in the text area, not in the margin.

So if we want consistency between the GUI and TTY frames, the
left-truncation indicator should be to the left of the line numbers on
TTY frames as well.

> > 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.
> 
> Depends on what we call long lines. I run Emacs in two windows
> side-by-side on a 24″ monitor, so for me everything exceeding ≈100
> columns is a long line. My teammates sometimes break this limit, and
> some teams in the company I work for have a 120-column coding
> standard.

IME, lines longer than 80 columns are frowned upon in many coding
standards.  It's certainly so in Emacs and on my daytime job.  And
even if such long lines are allowed, I presume most of the lines are
way shorter, at least in some popular languages.

I'm not saying long lines never happen, I'm saying this is a clear
80-20 situation, and IMO we should favor the majority.

> > 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.
> 
> The problem here is that there isn’t a defined protocol for sharing
> the margin. There was a discussion in 2015-12 on that matter.
> 
> https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00066.html

Indeed we discussed this more than once, but the problem is still
unsolved, and AFAIR we were unable to even reach a consensus, let
alone design the solution.  Which to me means the problem is really
hard to solve.  Working around hard problems is a good engineering
practice.