bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Paul Rankin]

display-line-numbers-mode does not respect line-prefix or wrap-prefix text properties when set as '(space :align-to N).

To reproduce:

1. emacs -Q
3. type some text in *scratch* buffer
2. M-: (put-text-property (line-beginning-position) (line-end-position) 'line-prefix '(space :align-to 2))
3. M-x display-line-numbers-mode

Expected results:

Line numbers should be displayed before line-prefix (and/or wrap-prefix) space of 2 columns.

Actual results:

Line numbers eat the line-prefix and wrap-prefix space, effectively aligning the text back to 0.

Configuration:

GNU Emacs 26.0.90 (build 1, x86_64-apple-darwin17.0.0) of 2017-10-15
macOS 10.13 (17A405)

MacBook Pro (Retina, 15-inch, Mid 2015)
2.2 GHz Intel Core i7
16 GB 1600 MHz DDR3
Intel Iris Pro 1536 MB

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Eli Zaretskii]

> From: Paul Rankin <hello@paulwrankin.com>
> Date: Mon, 16 Oct 2017 13:38:11 +1000
> 
> display-line-numbers-mode does not respect line-prefix or wrap-prefix text properties when set as '(space :align-to N).
> 
> To reproduce:
> 
> 1. emacs -Q
> 3. type some text in *scratch* buffer
> 2. M-: (put-text-property (line-beginning-position) (line-end-position) 'line-prefix '(space :align-to 2))
> 3. M-x display-line-numbers-mode
> 
> Expected results:
> 
> Line numbers should be displayed before line-prefix (and/or wrap-prefix) space of 2 columns.
> 
> Actual results:
> 
> Line numbers eat the line-prefix and wrap-prefix space, effectively aligning the text back to 0.

Right, :align-to still counts from the window edge, even when line
numbers are displayed, whereas you expected it to count from the end
of the line-number display.

When this was briefly discussed during development, we decided not to
change the reported window dimensions and geometry, including those of
the text area, to account for the screen estate taken by the
line-number display.  But maybe :align-to should be an exception, when
used to align buffer text (as opposed to header-line or mode-line)?
Though I'm bothered whether some users of :align-to may not want this
automatic offset.  :align-to is a very popular feature; does anyone
know or imagine why a Lisp program would NOT like such an offset?

What do people think?  Dmitry, what about company-mode popups, for
example?

It should be a very easy change to offset the origin for every use of
:align-to for buffer text: it's basically a single line of code in a
single place.  But if some applications won't want that, we will
probably need an entirely new attribute, which is much less nice, IMO.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Paul Rankin]

On Tue, 17 Oct 2017, at 02:05 AM, Eli Zaretskii wrote:
> Right, :align-to still counts from the window edge, even when line
> numbers are displayed, whereas you expected it to count from the end
> of the line-number display.

linum-mode.el (in 26.x) manages to display line numbers without interfering, so it’s really just about display-line-numbers-mode.

> When this was briefly discussed during development, we decided not to
> change the reported window dimensions and geometry, including those of
> the text area, to account for the screen estate taken by the
> line-number display.  But maybe :align-to should be an exception, when
> used to align buffer text (as opposed to header-line or mode-line)?
> Though I'm bothered whether some users of :align-to may not want this
> automatic offset.  :align-to is a very popular feature; does anyone
> know or imagine why a Lisp program would NOT like such an offset?

Citing other discussions is not really relevant, if there’s a problem there’s a problem. User expectation is if a user writes codes following the Elisp manual, the expectation is that it should continue to work. In this case, using :align-to should align to its specified value.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Eli Zaretskii]

> From: Paul Rankin <hello@paulwrankin.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, 28855@debbugs.gnu.org
> Date: Tue, 17 Oct 2017 10:47:11 +1000
> 
> On Tue, 17 Oct 2017, at 02:05 AM, Eli Zaretskii wrote:
> > Right, :align-to still counts from the window edge, even when line
> > numbers are displayed, whereas you expected it to count from the end
> > of the line-number display.
> 
> linum-mode.el (in 26.x) manages to display line numbers without interfering, so it’s really just about display-line-numbers-mode.

Yes, of course.  linum-mode displays the numbers in the display
margin, and keeping off the margins was an explicit design goal of
display-line-numbers-mode.

> > When this was briefly discussed during development, we decided not to
> > change the reported window dimensions and geometry, including those of
> > the text area, to account for the screen estate taken by the
> > line-number display.  But maybe :align-to should be an exception, when
> > used to align buffer text (as opposed to header-line or mode-line)?
> > Though I'm bothered whether some users of :align-to may not want this
> > automatic offset.  :align-to is a very popular feature; does anyone
> > know or imagine why a Lisp program would NOT like such an offset?
> 
> Citing other discussions is not really relevant, if there’s a problem there’s a problem. User expectation is if a user writes codes following the Elisp manual, the expectation is that it should continue to work. In this case, using :align-to should align to its specified value.

:align-to does align to its value, it just doesn't currently update it
to account for the space taken by line numbers.

It's clear that the change I have in mind will solve your specific
problem, I just want to hear from others whether it could harm
something.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Eli Zaretskii]

On October 17, 2017 5:44:51 AM GMT+03:00, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Paul Rankin <hello@paulwrankin.com>
> > Cc: Dmitry Gutov <dgutov@yandex.ru>, 28855@debbugs.gnu.org
> > Date: Tue, 17 Oct 2017 10:47:11 +1000
> > 
> > On Tue, 17 Oct 2017, at 02:05 AM, Eli Zaretskii wrote:
> > > Right, :align-to still counts from the window edge, even when line
> > > numbers are displayed, whereas you expected it to count from the
> end
> > > of the line-number display.
> > 
> > linum-mode.el (in 26.x) manages to display line numbers without
> interfering, so it’s really just about display-line-numbers-mode.
> 
> Yes, of course.  linum-mode displays the numbers in the display
> margin, and keeping off the margins was an explicit design goal of
> display-line-numbers-mode.
> 
> > > When this was briefly discussed during development, we decided not
> to
> > > change the reported window dimensions and geometry, including
> those of
> > > the text area, to account for the screen estate taken by the
> > > line-number display.  But maybe :align-to should be an exception,
> when
> > > used to align buffer text (as opposed to header-line or
> mode-line)?
> > > Though I'm bothered whether some users of :align-to may not want
> this
> > > automatic offset.  :align-to is a very popular feature; does
> anyone
> > > know or imagine why a Lisp program would NOT like such an offset?
> > 
> > Citing other discussions is not really relevant, if there’s a
> problem there’s a problem. User expectation is if a user writes codes
> following the Elisp manual, the expectation is that it should continue
> to work. In this case, using :align-to should align to its specified
> value.
> 
> :align-to does align to its value, it just doesn't currently update it
> to account for the space taken by line numbers.
> 
> It's clear that the change I have in mind will solve your specific
> problem, I just want to hear from others whether it could harm
> something.

Btw, in case it wasn't clear: a solution for this is already available --
use line-number-display-width when computing the value of :align-to.
Like tabulated-list-mode already does.

I'm just trying to establish if a more convenient solution could be possible.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Paul Rankin]

On Tue, 17 Oct 2017, at 02:04 PM, Eli Zaretskii wrote:
> > :align-to does align to its value, it just doesn't currently update it
> > to account for the space taken by line numbers.

Justifying a bug doesn’t fix it.

> > It's clear that the change I have in mind will solve your specific
> > problem, I just want to hear from others whether it could harm
> > something.
> 
> Btw, in case it wasn't clear: a solution for this is already available --
> use line-number-display-width when computing the value of :align-to.
> Like tabulated-list-mode already does.
> 
> I'm just trying to establish if a more convenient solution could be possible.

Further to the cited discussion, if taken to its logical conclusions, this approach reaches a point of absurdity, e.g.

Three lines with respective :align-to property values of 0, 2 and 4 should appear like this:

    foo
      bar
        baz

However what we get when these lines occur at line 1000 with display-line-numbers-mode enabled is:

    1000 foo
    1001 bar
    1002 baz

Or, given that the line numbers take up a width of 4 characters, and we don’t account for this width, then logically do we now truncate the leading 4 and 2 characters....?

    1000 
    1001 r
    1002 baz

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Eli Zaretskii]

On October 17, 2017 7:32:18 AM GMT+03:00, Paul Rankin <hello@paulwrankin.com> wrote:
> On Tue, 17 Oct 2017, at 02:04 PM, Eli Zaretskii wrote:
> > > :align-to does align to its value, it just doesn't currently
> update it
> > > to account for the space taken by line numbers.
> 
> Justifying a bug doesn’t fix it.
> 
> > > It's clear that the change I have in mind will solve your specific
> > > problem, I just want to hear from others whether it could harm
> > > something.
> > 
> > Btw, in case it wasn't clear: a solution for this is already
> available --
> > use line-number-display-width when computing the value of :align-to.
> > Like tabulated-list-mode already does.
> > 
> > I'm just trying to establish if a more convenient solution could be
> possible.
> 
> Further to the cited discussion, if taken to its logical conclusions,
> this approach reaches a point of absurdity, e.g.
> 
> Three lines with respective :align-to property values of 0, 2 and 4
> should appear like this:
> 
>     foo
>       bar
>         baz
> 
> However what we get when these lines occur at line 1000 with
> display-line-numbers-mode enabled is:
> 
>     1000 foo
>     1001 bar
>     1002 baz
> 
> Or, given that the line numbers take up a width of 4 characters, and
> we don’t account for this width, then logically do we now truncate the
> leading 4 and 2 characters....?
> 
>     1000 
>     1001 r
>     1002 baz

Not sure what is alluded to as "this approach".

My last point is that instead of 0, 2, and 4, you can use those values plus what
line-number-display-width returns, and then you will have your expected
result.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Paul Rankin]

On Tue, 17 Oct 2017, at 03:49 PM, Eli Zaretskii wrote:
> > Further to the cited discussion, if taken to its logical conclusions,
> > this approach reaches a point of absurdity, e.g.
> > 
> > Three lines with respective :align-to property values of 0, 2 and 4
> > should appear like this:
> > 
> >     foo
> >       bar
> >         baz
> > 
> > However what we get when these lines occur at line 1000 with
> > display-line-numbers-mode enabled is:
> > 
> >     1000 foo
> >     1001 bar
> >     1002 baz
> > 
> > Or, given that the line numbers take up a width of 4 characters, and
> > we don’t account for this width, then logically do we now truncate the
> > leading 4 and 2 characters....?
> > 
> >     1000 
> >     1001 r
> >     1002 baz
> 
> Not sure what is alluded to as "this approach".

Current implementation.

> My last point is that instead of 0, 2, and 4, you can use those values plus what
> line-number-display-width returns, and then you will have your expected
> result.

It’s not the responsibility of others to work around problems you create. I’ve done my part by identifying the bug. That’s as far as I wish to be involved.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Dmitry Gutov]

Hi Eli,

On 10/16/17 7:05 PM, Eli Zaretskii wrote:

> When this was briefly discussed during development, we decided not to
> change the reported window dimensions and geometry, including those of
> the text area, to account for the screen estate taken by the
> line-number display.

FTR, I'd have preferred for the line numbers to be considered outside of 
the window edge, together with fringes and margins. And I still don't 
see any downside to it (except it might be harder to implement).

As it is now, third-party code has to adapt instead, by handling the 
line numbers specially.

> But maybe :align-to should be an exception, when
> used to align buffer text (as opposed to header-line or mode-line)?
> Though I'm bothered whether some users of :align-to may not want this
> automatic offset.  :align-to is a very popular feature; does anyone
> know or imagine why a Lisp program would NOT like such an offset?
> 
> What do people think?  Dmitry, what about company-mode popups, for
> example?

Not sure. What about them? We don't use align-to in the popups (though 
we could, for space-only offsets, now that I've read about this spec; 
not sure if the change will be worth it, performance or memory-wise).

And as for align-to's used in the buffer text, we probably don't support 
them very well, but the proposed change shouldn't make it any worse, I 
think.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Eli Zaretskii]

> Cc: 28855@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 18 Oct 2017 12:29:08 +0300
> 
> FTR, I'd have preferred for the line numbers to be considered outside of 
> the window edge, together with fringes and margins. And I still don't 
> see any downside to it (except it might be harder to implement).

Well, "harder to implement" is very relevant here ;-)

Also, "outside of the window edge" has implications besides text
layout, and I trust Martin's judgment (which happens to match mine)
that we should try letting those sleeping dogs lie.

In any case, this opinion of yours probably means that having
:align-to automatically update its offsets to account for the line
numbers is in the direction you wanted Emacs to go, albeit not all the
way, right?  I mean, it does make Emacs behave as if line numbers were
not part of the text area in this case.

> As it is now, third-party code has to adapt instead, by handling the 
> line numbers specially.

Yes.  But this is nothing new, it happens with almost every
display-related feature.

> > But maybe :align-to should be an exception, when
> > used to align buffer text (as opposed to header-line or mode-line)?
> > Though I'm bothered whether some users of :align-to may not want this
> > automatic offset.  :align-to is a very popular feature; does anyone
> > know or imagine why a Lisp program would NOT like such an offset?
> > 
> > What do people think?  Dmitry, what about company-mode popups, for
> > example?
> 
> Not sure. What about them? We don't use align-to in the popups (though 
> we could, for space-only offsets, now that I've read about this spec; 
> not sure if the change will be worth it, performance or memory-wise).
> 
> And as for align-to's used in the buffer text, we probably don't support 
> them very well, but the proposed change shouldn't make it any worse, I 
> think.

OK, thanks.

Martin, any comments or thoughts about this, before I go out and make
the code changes to implement this?

Anybody else?  Stefan? John?

TIA

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[martin rudalics]

 > Martin, any comments or thoughts about this, before I go out and make
 > the code changes to implement this?

I'd make the change.  If someone wants the current behavior, we could add
a "special element" like 'line-number-display-start' such that

:align-to 0

would behave like

:align-to (+ line-number-display-start (line-number-display-width t))

for LTR text.  But I never use :align-to so I'm not very qualified to
comment on this.

martin

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Eli Zaretskii]

> Date: Wed, 18 Oct 2017 19:44:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 28855@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>, 
>  John Wiegley <johnw@gnu.org>
> 
>  > Martin, any comments or thoughts about this, before I go out and make
>  > the code changes to implement this?
> 
> I'd make the change.

OK, will do.

> If someone wants the current behavior, we could add
> a "special element" like 'line-number-display-start' such that
> 
> :align-to 0
> 
> would behave like
> 
> :align-to (+ line-number-display-start (line-number-display-width t))
> 
> for LTR text.

I don't think this addition would be needed, since :align-to already
supports several elements which I intend to leave alone: left-fringe,
left-margin, and scroll-bar.  Offsets relative to these will not be
affected by line numbers, because I don't think that would make sense.
Only 'left', 'center' and bare numerical offsets will be affected, and
'text' will be affected to yield the width of the text area sans the
space taken by line numbers.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Eli Zaretskii]

> Date: Wed, 18 Oct 2017 20:55:20 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 28855@debbugs.gnu.org, monnier@iro.umontreal.ca, johnw@gnu.org,
> 	dgutov@yandex.ru
> 
> > Date: Wed, 18 Oct 2017 19:44:50 +0200
> > From: martin rudalics <rudalics@gmx.at>
> > CC: 28855@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>, 
> >  John Wiegley <johnw@gnu.org>
> > 
> >  > Martin, any comments or thoughts about this, before I go out and make
> >  > the code changes to implement this?
> > 
> > I'd make the change.
> 
> OK, will do.

Now done on the release branch.  I'm therefore marking the bug done.

Thanks to everyone who provided feedback and ideas in this
discussions.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Eli Zaretskii]

> Date: Wed, 18 Oct 2017 19:44:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 28855@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>, 
>  John Wiegley <johnw@gnu.org>
> 
> If someone wants the current behavior, we could add
> a "special element" like 'line-number-display-start' such that
> 
> :align-to 0
> 
> would behave like
> 
> :align-to (+ line-number-display-start (line-number-display-width t))
> 
> for LTR text.

Actually, it's the other way around: the current behavior is that
:align-to always starts counting from the window edge, even if line
numbers are displayed, so the effect of ":align-to N" is as if N has
been reduced by the screen space used for displaying the numbers.  The
changes I'm about to install make :align-to work as you described
above, i.e. start measuring the offset from where the line-number
display ends.

After the change, if someone wants to always measure the offset from
the window edge, they could/should use

  :align-to (+ left-fringe left-fringe N)

Here the first occurrence of left-fringe stands for the position of
the left edge of the left fringe, and the second occurrence stands for
the width of the left fringe (these rules were always in effect, see
the ELisp manual, under "Pixel Specification").

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[martin rudalics]

 > After the change, if someone wants to always measure the offset from
 > the window edge, they could/should use
 >
 >    :align-to (+ left-fringe left-fringe N)

Unless ‘fringes-outside-margins’ is non-nil and there's a left margin.

martin

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Eli Zaretskii]

> Date: Wed, 18 Oct 2017 20:34:37 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, 28855@debbugs.gnu.org, monnier@iro.umontreal.ca, 
>  johnw@gnu.org
> 
>  > After the change, if someone wants to always measure the offset from
>  > the window edge, they could/should use
>  >
>  >    :align-to (+ left-fringe left-fringe N)
> 
> Unless ‘fringes-outside-margins’ is non-nil and there's a left margin.

For that, there's left-margin that can play the same role.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 18 Oct 2017 19:44:50 +0200
>> From: martin rudalics <rudalics@gmx.at>
>> CC: 28855@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>, 
>>  John Wiegley <johnw@gnu.org>
>> 
>> If someone wants the current behavior, we could add
>> a "special element" like 'line-number-display-start' such that
>> 
>> :align-to 0
>> 
>> would behave like
>> 
>> :align-to (+ line-number-display-start (line-number-display-width t))
>> 
>> for LTR text.
>
> Actually, it's the other way around: the current behavior is that
> :align-to always starts counting from the window edge, even if line
> numbers are displayed, so the effect of ":align-to N" is as if N has
> been reduced by the screen space used for displaying the numbers.

By "window edge" do you mean the edge of the text area? Since AFAICT
there's no current way to specify alignment relative to the window
edges. This is what the 2nd part of Bug#28771 is about.

> The changes I'm about to install make :align-to work as you described
> above, i.e. start measuring the offset from where the line-number
> display ends.

What about starting the measurement from after the line-prefix attribute
as well? Then there can be a new element for pixel specs that one can
use to display relative to line numbers, if one so wishes.

> After the change, if someone wants to always measure the offset from
> the window edge, they could/should use
>
>   :align-to (+ left-fringe left-fringe N)

> > Unless ‘fringes-outside-margins’ is non-nil and there's a left margin.
> For that, there's left-margin that can play the same role.

If there's a distinct element for line-numbers, then you don't have to
worry about what elements are on the left, or what order they're in.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>,  28855@debbugs.gnu.org,  monnier@iro.umontreal.ca,  johnw@gnu.org,  dgutov@yandex.ru
> Date: Wed, 18 Oct 2017 17:58:03 -0600
> 
> > Actually, it's the other way around: the current behavior is that
> > :align-to always starts counting from the window edge, even if line
> > numbers are displayed, so the effect of ":align-to N" is as if N has
> > been reduced by the screen space used for displaying the numbers.
> 
> By "window edge" do you mean the edge of the text area?

Yes (although it turned out during a previous discussion that "text
area" is not understood the same by all the parties ;-)

> Since AFAICT there's no current way to specify alignment relative to
> the window edges. This is what the 2nd part of Bug#28771 is about.

You are talking about header-line, otherwise such origin makes little
sense.  As I said in that bug, I'd rather provide higher-level
features, like centering a string in the header-line regardless of
whatever factors can affect the centering.  Assuming that your request
is motivated by such layout requirements, that is.  (But let's not
talk here about the issues raised there.)

> > The changes I'm about to install make :align-to work as you described
> > above, i.e. start measuring the offset from where the line-number
> > display ends.
> 
> What about starting the measurement from after the line-prefix attribute
> as well?

I don't plan doing that, certainly not for Emacs 26.  The line-prefix
and wrap-prefix are very old features, and no one asked for :align-to
to know about them till now, so presumably it isn't very important.
(It also sounds like :align-to itself is rarely used and sometimes is
entirely unfamiliar-with.  I certainly don't see some of its features
used in Emacs at all, which makes me wonder why did we implement them
in Emacs 21.)

> > After the change, if someone wants to always measure the offset from
> > the window edge, they could/should use
> >
> >   :align-to (+ left-fringe left-fringe N)
> 
> > > Unless ‘fringes-outside-margins’ is non-nil and there's a left margin.
> > For that, there's left-margin that can play the same role.
> 
> If there's a distinct element for line-numbers, then you don't have to
> worry about what elements are on the left, or what order they're in.

My assumption is that no one will need to worry about that because
everybody will want the automatic accounting for the line numbers I'm
about to implement.  The above is just a fire escape I don't envision
to be needed, certainly not frequently.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes (although it turned out during a previous discussion that "text
> area" is not understood the same by all the parties ;-)

Yeah, my bad (though now I'm using the definition from (elisp) Window
Sizes :-).

>> What about starting the measurement from after the line-prefix attribute
>> as well?
>
> I don't plan doing that, certainly not for Emacs 26.  The line-prefix
> and wrap-prefix are very old features, and no one asked for :align-to
> to know about them till now, so presumably it isn't very important.
> (It also sounds like :align-to itself is rarely used and sometimes is
> entirely unfamiliar-with.  I certainly don't see some of its features
> used in Emacs at all, which makes me wonder why did we implement them
> in Emacs 21.)

It doesn't seem that line/wrap-prefix are very commonly used (though
perhaps I'm just not using the relevant packages), so coupled with
:align-to's rarity it doesn't seem surprising that no one has asked for
it until now.

Anyway, my argument is still that I believe a default starting point
past the *-prefix area is more intuitive than before it. I figured that
since you brought up changing the default starting point, that I might
as well run it by you again.

Just accounting for line-numbers is better than the current behaviour,
but if you do decide to do that, then it would be nice to have something
along the lines of:

  :align-to (+ prefix prefix N)

That would mean "offset from the *-prefix area", which would let you
align to non-prefix text in the buffer.

>> If there's a distinct element for line-numbers, then you don't have to
>> worry about what elements are on the left, or what order they're in.
>
> My assumption is that no one will need to worry about that because
> everybody will want the automatic accounting for the line numbers I'm
> about to implement.  The above is just a fire escape I don't envision
> to be needed, certainly not frequently.

I think it's unlikely that one would want to account for line-numbers
and not line/wrap-prefix, but I figure that it would be nice to provide
a flexible fire escape.

Still, if alignment treats line-numbers specially, then I think it makes
sense to provide it as a full-fledged element for pixel specifications.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: rudalics@gmx.at,  28855@debbugs.gnu.org,  monnier@iro.umontreal.ca,  johnw@gnu.org,  dgutov@yandex.ru
> Date: Wed, 18 Oct 2017 23:54:54 -0600
> 
> It doesn't seem that line/wrap-prefix are very commonly used (though
> perhaps I'm just not using the relevant packages), so coupled with
> :align-to's rarity it doesn't seem surprising that no one has asked for
> it until now.

I'd prefer not to put too much effort into developing new aspects of
never-used combinations of features.  IME, we already have too many
such combinations, and that gets in the way of new developments due to
the need to keep them compatible to existing features, and our general
inability to decide that some such feature can be safely removed.

> Just accounting for line-numbers is better than the current behaviour,
> but if you do decide to do that, then it would be nice to have something
> along the lines of:
> 
>   :align-to (+ prefix prefix N)
> 
> That would mean "offset from the *-prefix area", which would let you
> align to non-prefix text in the buffer.

But the prefixes are different: there could be a different prefix for
each line, defined via the property set on that line.  So using that
in conjunction with :align-to makes much less sense, since most uses
of :align-to are for aligning text on more than one line.

> Still, if alignment treats line-numbers specially, then I think it makes
> sense to provide it as a full-fledged element for pixel specifications.

It has never been a principle of Emacs development to develop each
feature to its logical endpoint.  We only develop what's practically
needed and makes most sense, and do that pragmatically.

Once again, too many of these features imply we have some
unimplemented layout requirements, and if so, we will be better off
implementing that layout entirely in the display engine, instead of
giving Lisp programs more hooks into the display code.  Doing layout
in Lisp should generally be avoided.

bug#28855: 26.0.90; display-line-numbers-mode does not respect (line|wrap)-prefix '(space :align-to N) text property

[Dmitry Gutov]

On 10/18/17 7:47 PM, Eli Zaretskii wrote:

> Well, "harder to implement" is very relevant here ;-)
> 
> Also, "outside of the window edge" has implications besides text
> layout, and I trust Martin's judgment (which happens to match mine)
> that we should try letting those sleeping dogs lie.

I get that it might have been too difficult to work out in time for 
Emacs 26, but here's hoping we'll get it sorted out in some later release.

> In any case, this opinion of yours probably means that having
> :align-to automatically update its offsets to account for the line
> numbers is in the direction you wanted Emacs to go, albeit not all the
> way, right?  I mean, it does make Emacs behave as if line numbers were
> not part of the text area in this case.

Yes, but it might be not as beneficial when some other features do react 
to line numbers. Still, seems like the better choice here.

>> As it is now, third-party code has to adapt instead, by handling the
>> line numbers specially.
> 
> Yes.  But this is nothing new, it happens with almost every
> display-related feature.

Not every new feature has to become a new display-related feature, though.