Re: Native display of line numbers

[Yuri Khan]

On Mon, Jun 19, 2017 at 2:00 AM, Eli Zaretskii <address@hidden> wrote:

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

Until now, there were two facilities (fringe and margin) and their
order was customizable via one boolean variable,
‘fringes-outside-margin’. By default, it is nil so fringes are inside
and thus closer to the text than line numbers displayed in the
margins.

How much is too much is subjective.

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

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

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. Whenever I need to read their code, I get annoyed at them;
ideally, my tool would help me cope with that annoyance, not
exacerbate it.

> 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