Using :align-to with non-spaces

Using :align-to with non-spaces

[Alex]

Would it be a reasonable feature request to allow some usage of
:align-to with non-spaces (or to have a special display property for
alignment)? For instance, imagine one wants to align a string in the
header-line with the text area. Compare:


(setq header-line-format
      (concat (propertize " "
                          'display
                          '(space . (:align-to 0)))
              "test"))

(setq header-line-format
      (propertize "test"
                  'display
                  '(space . (:align-to 0))))

It's not a big deal, but it's makes things look cleaner, especially when
the string in question is also being propertized.

P.S. I noticed that the above does not take into account the space taken
by `display-line-numbers'.

Re: Using :align-to with non-spaces

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: eliz@gnu.org
> Date: Sun, 08 Oct 2017 23:22:59 -0600
> 
> (setq header-line-format
>       (concat (propertize " "
>                           'display
>                           '(space . (:align-to 0)))
>               "test"))
> 
> (setq header-line-format
>       (propertize "test"
>                   'display
>                   '(space . (:align-to 0))))
> 
> It's not a big deal, but it's makes things look cleaner, especially when
> the string in question is also being propertized.

The 'space' display property is of the "replacing" kind, i.e. it
completely replaces the text which has that property.  So implementing
what you want would need a new property at least.  Or maybe you could
use the '(space-width FACTOR)' display spec instead, and prepending a
single SPC character that precedes the string characters?  (This
assumes the string itself doesn't have embedded SPC characters; if it
does, put this display property only on the initial SPC character.)

FWIW, having a 'space' display property on some whitespace character
sounds very intuitive to me, since this feature was supposed to be
used to display white space subject to pixel-level resolution
considerations of a GUI frame.

> P.S. I noticed that the above does not take into account the space taken
> by `display-line-numbers'.

That's because it isn't clear whether it should be done for every
header-line.  For example, the Info mode will certainly not want
that.  So this has to be done by the Lisp program, because only it
knows whether the text in the header line should be aligned with the
rest of buffer text.

Re: Using :align-to with non-spaces

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: eliz@gnu.org
>> Date: Sun, 08 Oct 2017 23:22:59 -0600
>> 
>> (setq header-line-format
>>       (concat (propertize " "
>>                           'display
>>                           '(space . (:align-to 0)))
>>               "test"))
>> 
>> (setq header-line-format
>>       (propertize "test"
>>                   'display
>>                   '(space . (:align-to 0))))
>> 
>> It's not a big deal, but it's makes things look cleaner, especially when
>> the string in question is also being propertized.
>
> The 'space' display property is of the "replacing" kind, i.e. it
> completely replaces the text which has that property.  So implementing
> what you want would need a new property at least.  Or maybe you could
> use the '(space-width FACTOR)' display spec instead, and prepending a
> single SPC character that precedes the string characters?  (This
> assumes the string itself doesn't have embedded SPC characters; if it
> does, put this display property only on the initial SPC character.)

I guess I replied to this part in Bug#28771 (sorry for fragmenting the
discussion).

> FWIW, having a 'space' display property on some whitespace character
> sounds very intuitive to me, since this feature was supposed to be
> used to display white space subject to pixel-level resolution
> considerations of a GUI frame.

It does to me as well, but it would be nice to have similar
functionality to :align-to in arbitrary strings.

Something like the following, that would align the string similar to
:align-to does a space:

(propertize "test"
            'display
            '(align-to EXPR))

where EXPR can be the same as in :align-to.

>> P.S. I noticed that the above does not take into account the space taken
>> by `display-line-numbers'.
>
> That's because it isn't clear whether it should be done for every
> header-line.  For example, the Info mode will certainly not want
> that.  So this has to be done by the Lisp program, because only it
> knows whether the text in the header line should be aligned with the
> rest of buffer text.

I don't understand. The Info mode header isn't aligned at all (for
example, toggling fringe and linum-mode (for the margin) doesn't change
the position of the info header). Only headers with an `:align-to num'
property would be affected.

Here is what the manual says about :align-to:

   For example, ‘:align-to 0’ in a header-line aligns with the first
   text column in the text area.

I would consider "the first text column" to be column 0, so the current
behaviour is incorrect.

If line-number display is treated specially, then there should also be a
`line-number' element for the :align-to and :width specs.

Re: Using :align-to with non-spaces

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Tue, 10 Oct 2017 12:09:53 -0600
> 
> > FWIW, having a 'space' display property on some whitespace character
> > sounds very intuitive to me, since this feature was supposed to be
> > used to display white space subject to pixel-level resolution
> > considerations of a GUI frame.
> 
> It does to me as well, but it would be nice to have similar
> functionality to :align-to in arbitrary strings.
> 
> Something like the following, that would align the string similar to
> :align-to does a space:
> 
> (propertize "test"
>             'display
>             '(align-to EXPR))
> 
> where EXPR can be the same as in :align-to.

:align-to doesn't align the space, it produces a stretch of white
space that _ends_ at the place which :align-to defines.  That's why it
makes sense to put this property on a SPC character: it makes that SPC
character's width on display be as you need it.

> I don't understand. The Info mode header isn't aligned at all (for
> example, toggling fringe and linum-mode (for the margin) doesn't change
> the position of the info header). Only headers with an `:align-to num'
> property would be affected.

Ah, you want :align-to take the line numbers into consideration!

It doesn't because neither does that happen with line-prefix or
wrap-prefix.  IOW, :align-to measures from the edges of the window's
text area.

> Here is what the manual says about :align-to:
> 
>    For example, ‘:align-to 0’ in a header-line aligns with the first
>    text column in the text area.
> 
> I would consider "the first text column" to be column 0, so the current
> behaviour is incorrect.

The "text area" is everything inside the fringes/display margins
(whichever comes last), so it includes the space used for the
line-number display.

> If line-number display is treated specially

It isn't: it is treated the same as line-prefix and wrap-prefix.

> then there should also be a `line-number' element for the :align-to
> and :width specs.

The solution I can suggest is to use the value returned by
line-number-display-width.

Re: Using :align-to with non-spaces

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Tue, 10 Oct 2017 12:09:53 -0600
>>
>> It does to me as well, but it would be nice to have similar
>> functionality to :align-to in arbitrary strings.
>> 
>> Something like the following, that would align the string similar to
>> :align-to does a space:
>> 
>> (propertize "test"
>>             'display
>>             '(align-to EXPR))
>> 
>> where EXPR can be the same as in :align-to.
>
> :align-to doesn't align the space, it produces a stretch of white
> space that _ends_ at the place which :align-to defines.  That's why it
> makes sense to put this property on a SPC character: it makes that SPC
> character's width on display be as you need it.

Right, I misspoke. What would be nice is to have the above 'align-to
display property prepend a stretch space that ends at an :align-to
expression. I believe it makes the code a bit neater when using other
text properties on the string.

>> I don't understand. The Info mode header isn't aligned at all (for
>> example, toggling fringe and linum-mode (for the margin) doesn't change
>> the position of the info header). Only headers with an `:align-to num'
>> property would be affected.
>
> Ah, you want :align-to take the line numbers into consideration!
>
> It doesn't because neither does that happen with line-prefix or
> wrap-prefix.  IOW, :align-to measures from the edges of the window's
> text area.

I would consider it not recognizing {line,wrap}-prefix to be a bug as
well (either in behaviour or documentation).

>> Here is what the manual says about :align-to:
>> 
>>    For example, ‘:align-to 0’ in a header-line aligns with the first
>>    text column in the text area.
>> 
>> I would consider "the first text column" to be column 0, so the current
>> behaviour is incorrect.
>
> The "text area" is everything inside the fringes/display margins
> (whichever comes last), so it includes the space used for the
> line-number display.

From a user perspective, I don't think the prefix/line-numbers should be
considered as part of the text area. At the very least, not the
line-numbers. Essentially, I believe a user should ideally be able to
liken the display-line-numbers area to a "non-customizable second
margin", if that makes sense.

>> If line-number display is treated specially
>
> It isn't: it is treated the same as line-prefix and wrap-prefix.

Okay, then there should be a `prefix' element that includes all of
these.

>> then there should also be a `line-number' element for the :align-to
>> and :width specs.
>
> The solution I can suggest is to use the value returned by
> line-number-display-width.

Right, but shouldn't it be recomputed at the same times that the other
element's widths are (i.e., toggling display-line-numbers should
automatically change the display width of relevant :align-to/:width
spaces)?

So even if `left' doesn't mean column 0 (I find this poor behaviour,
though), then one can use `(:align-to (+ left prefix)' or something of
the sort to always mean column 0, even if there are
prefixes/line-numbers displayed.

Re: Using :align-to with non-spaces

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Tue, 10 Oct 2017 13:18:24 -0600
> 
> > :align-to doesn't align the space, it produces a stretch of white
> > space that _ends_ at the place which :align-to defines.  That's why it
> > makes sense to put this property on a SPC character: it makes that SPC
> > character's width on display be as you need it.
> 
> Right, I misspoke. What would be nice is to have the above 'align-to
> display property prepend a stretch space that ends at an :align-to
> expression.

Then the stretch would have no buffer/string position on it, and the
code which processes glyphs would become more complex.  IMO, the gain
is too small to justify the complexity.

> I believe it makes the code a bit neater when using other text
> properties on the string.

If it does, then only slightly so, IMO.  Prepending a space is not a
big deal.

> > It doesn't because neither does that happen with line-prefix or
> > wrap-prefix.  IOW, :align-to measures from the edges of the window's
> > text area.
> 
> I would consider it not recognizing {line,wrap}-prefix to be a bug as
> well (either in behaviour or documentation).

Everything in the text area counts: images, stretches, line numbers,
etc.  This was always so, since Emacs 21.

> > The "text area" is everything inside the fringes/display margins
> > (whichever comes last), so it includes the space used for the
> > line-number display.
> 
> >From a user perspective, I don't think the prefix/line-numbers should be
> considered as part of the text area.  At the very least, not the
> line-numbers.

That's your linum-mode experience talking ;-)  It takes time to get
used to a different view of this.

> > The solution I can suggest is to use the value returned by
> > line-number-display-width.
> 
> Right, but shouldn't it be recomputed at the same times that the other
> element's widths are (i.e., toggling display-line-numbers should
> automatically change the display width of relevant :align-to/:width
> spaces)?

We discussed that briefly on emacs-devel, and decided not to, mainly
due to the line/wrap-prefix precedent.  I still don't see any reason
to revise that decision, the few problems that are caused for that
were solved relatively easily.

> So even if `left' doesn't mean column 0 (I find this poor behaviour,
> though), then one can use `(:align-to (+ left prefix)' or something of
> the sort to always mean column 0, even if there are
> prefixes/line-numbers displayed.

I think you underestimate the number of different "things" that could
precede the leftmost text character.  We have so many display features
that can put stuff to the left of the leftmost character that we will
have hard time deciding what should and shouldn't be considered
'prefix'.  It is easier to write a function that computes their
summary width, if that's what you need.

More generally, doing layout in Lisp (which is what I think you are
trying) isn't easy, and was never supposed to be.  It is better to
extend the display engine to do layout for you, if that makes sense.

Re: Using :align-to with non-spaces

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> Right, I misspoke. What would be nice is to have the above 'align-to
>> display property prepend a stretch space that ends at an :align-to
>> expression.
>
> Then the stretch would have no buffer/string position on it, and the
> code which processes glyphs would become more complex.  IMO, the gain
> is too small to justify the complexity.

Sure, it's not worth it if the solution is complex.

>> I would consider it not recognizing {line,wrap}-prefix to be a bug as
>> well (either in behaviour or documentation).
>
> Everything in the text area counts: images, stretches, line numbers,
> etc.  This was always so, since Emacs 21.

Hmm, then I think that "(elisp) Pixel Specification" should include more
elements to account for these.

>> > The "text area" is everything inside the fringes/display margins
>> > (whichever comes last), so it includes the space used for the
>> > line-number display.
>> 
>> >From a user perspective, I don't think the prefix/line-numbers should be
>> considered as part of the text area.  At the very least, not the
>> line-numbers.
>
> That's your linum-mode experience talking ;-)  It takes time to get
> used to a different view of this.

I suppose so.

Still, I think that if it's not considered as part of the "text area",
then there should be some notion of `text area modulo
prefix/line-numbers' that :align-to/:width (and other parts of display,
perhaps) could use.

Then, I believe the default offset in "(elisp) Pixel Specification"
should be changed to the start of this construct (i.e., column 0). I
believe it would be a more user-friendly default.

>> > The solution I can suggest is to use the value returned by
>> > line-number-display-width.
>> 
>> Right, but shouldn't it be recomputed at the same times that the other
>> element's widths are (i.e., toggling display-line-numbers should
>> automatically change the display width of relevant :align-to/:width
>> spaces)?
>
> We discussed that briefly on emacs-devel, and decided not to, mainly
> due to the line/wrap-prefix precedent.  I still don't see any reason
> to revise that decision, the few problems that are caused for that
> were solved relatively easily.

What do you mean by "that"? I don't recall a discussion on this; the
closest I could find was:
https://lists.gnu.org/archive/html/emacs-devel/2017-06/msg00525.html

I think we misunderstand each other here (see below).

>> So even if `left' doesn't mean column 0 (I find this poor behaviour,
>> though), then one can use `(:align-to (+ left prefix)' or something of
>> the sort to always mean column 0, even if there are
>> prefixes/line-numbers displayed.
>
> I think you underestimate the number of different "things" that could
> precede the leftmost text character.  We have so many display features
> that can put stuff to the left of the leftmost character that we will
> have hard time deciding what should and shouldn't be considered
> 'prefix'.  It is easier to write a function that computes their
> summary width, if that's what you need.

Wouldn't anything between the left fringe and column 0 be considered
"prefix"?

Any "thing" that is in this area and applies to all lines should be
accounted for in "(elisp) Pixel Specification", IMO.

> More generally, doing layout in Lisp (which is what I think you are
> trying) isn't easy, and was never supposed to be.  It is better to
> extend the display engine to do layout for you, if that makes sense.

There appears to be some miscommunication here; I thought I was arguing
to extend the display engine (i.e., adding new values for `space'
display specifications).

Re: Using :align-to with non-spaces

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Tue, 10 Oct 2017 18:41:35 -0600
> 
> > Everything in the text area counts: images, stretches, line numbers,
> > etc.  This was always so, since Emacs 21.
> 
> Hmm, then I think that "(elisp) Pixel Specification" should include more
> elements to account for these.

What for?  If these are needed for doing layout in Lisp, then I'd
prefer to consider changes whereby the layout is completely done by
the display engine, if that is possible in the relevant use cases.

> Still, I think that if it's not considered as part of the "text area",
> then there should be some notion of `text area modulo
> prefix/line-numbers' that :align-to/:width (and other parts of display,
> perhaps) could use.

How is that different from using line-number-display-width in the
display spec?

> >> > The solution I can suggest is to use the value returned by
> >> > line-number-display-width.
> >> 
> >> Right, but shouldn't it be recomputed at the same times that the other
> >> element's widths are (i.e., toggling display-line-numbers should
> >> automatically change the display width of relevant :align-to/:width
> >> spaces)?
> >
> > We discussed that briefly on emacs-devel, and decided not to, mainly
> > due to the line/wrap-prefix precedent.  I still don't see any reason
> > to revise that decision, the few problems that are caused for that
> > were solved relatively easily.
> 
> What do you mean by "that"? I don't recall a discussion on this; the
> closest I could find was:
> https://lists.gnu.org/archive/html/emacs-devel/2017-06/msg00525.html

I meant this:

  http://lists.gnu.org/archive/html/emacs-devel/2017-06/msg00385.html

and Martin's response to it.

> > I think you underestimate the number of different "things" that could
> > precede the leftmost text character.  We have so many display features
> > that can put stuff to the left of the leftmost character that we will
> > have hard time deciding what should and shouldn't be considered
> > 'prefix'.  It is easier to write a function that computes their
> > summary width, if that's what you need.
> 
> Wouldn't anything between the left fringe and column 0 be considered
> "prefix"?

How can we know whether this will cause breakage all over the place?

> > More generally, doing layout in Lisp (which is what I think you are
> > trying) isn't easy, and was never supposed to be.  It is better to
> > extend the display engine to do layout for you, if that makes sense.
> 
> There appears to be some miscommunication here; I thought I was arguing
> to extend the display engine (i.e., adding new values for `space'
> display specifications).

You are arguing for extending the display engine with features that
are apparently intended to help Lisp programs do layout on the Lisp
level.  I'm saying that I'd be more happy if we could push _all_ of
the layout job in those cases into the display engine.  If possible,
of course.  E.g., if you want to be able to center the text of a
header-line in the window, why not ask the display engine do that for
you?

Re: Using :align-to with non-spaces

[Stefan Monnier]

>> Still, I think that if it's not considered as part of the "text area",
>> then there should be some notion of `text area modulo
>> prefix/line-numbers' that :align-to/:width (and other parts of display,
>> perhaps) could use.

FWIW, a notion of text-area modulo prefix would imply a non-rectangular
text-area, which I think would be a much bigger problem than what we
have now.

In this respect, the line-numbers are different (they could be
treated as a kind of margin).

> level.  I'm saying that I'd be more happy if we could push _all_ of
> the layout job in those cases into the display engine.  If possible,
> of course.  E.g., if you want to be able to center the text of a
> header-line in the window, why not ask the display engine do that for
> you?

Indeed.  Especially to handle the case where the same chunk of text is
displayed in several different frames (with different fonts, or with
a mix of GUI and tty frames).

One thing I'd like to see is a way to perform "right-alignment"
for things like tabulated-list-mode.


        Stefan

Re: Using :align-to with non-spaces

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 11 Oct 2017 20:47:52 -0400
> 
> One thing I'd like to see is a way to perform "right-alignment"
> for things like tabulated-list-mode.

You might be able to have it by starting the header string with a
u+200F RIGHT-TO-LEFT MARK (except that tabulated-list-mode might
outsmart you, I didn't try).

In any case, we already do something very similar for R2L paragraphs,
so implementing this should be very easy; I think the greatest
challenge is to come up with a natural way of telling the display
engine to do that.  Patches are welcome.