bug#65015: 29.1; align-to on wrapped line regression

[Axel Forsman]

> It was intentional, since :align-to counts columns, and columns in
> Emacs continue being counted in continuation lines, they don't start
> from zero again at the point where the line wraps.

But in that case this is still a documentation bug, since all
documentation refers to the value of :align-to as being a hpos and
not a col.

Where does the notion that :align-to takes a column come from?

> What you seem to expect would make it impossible
> to wrap lines with :align-to space display specs without losing the
> alignment when the line wraps.

More like "make it impossible to specify a :align-to value greater than
the width of the text area", because as you worded it, I would argue
the opposite holds. According to the docs,

    (concat "..." (propertize " " 'display `(space :align-to (- right
4))) "foo")

should right align the string "foo", however that alignment is lost now
in version 29 when the line has been wrapped, but not in 28.

Could you please link to the discussion where the old behavior was
termed a bug so I can read up?, because just from reading the Emacs
Lisp manual I am not so sure I agree.

Since it is easier to get the version 29 behavior using the min-width
property instead of :align-to (except that does not work in overlays?)
than the version 28 behavior, is there any chance this could be reverted?

I had an implementation of overlay-based popups working in Emacs 28
that used vertical-motion and :align-to to render the popup on the right
xy-positions regardless of where logical line breaks were. It cannot easily
be adapted for Emacs 29 since a lot of the work that the display engine
otherwise was doing now has to be done manually due to :align-to being
dumber.
So I have a bit of a bias toward the old :align-to workings.


/Axel Forsman

On Wed, Aug 2, 2023 at 4:40 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Axel Forsman <axelsfor@gmail.com>
> > Date: Wed, 2 Aug 2023 15:22:35 +0200
> >
> > I noticed that the interpretation of the hpos given to the :align-to
> > space specification property changed in Emacs 29.1 compared to 28.2,
> > without it being documented anywhere. In version 28 it counts relative
> > to the visual start of the line, whereas in version 29 it starts at the
> > logical start of the line.
> >
> > That is, the following MWE exhibits different visual behavior in Emacs
> > 28 contra 29:
> >
> >     (insert
> >      (concat
> >       "\n"
> >       (make-string (round (* 1.25 (window-text-width))) ?x)
> >       (propertize " " 'display `(space :align-to ,(round
> > (window-text-width) 2)))
> >       "foo\n\n"))
> >
> > (In 28 the text "foo" is centered correctly by the space. In 29 the
> > space has zero-width and no effect.)
> >
> > The previous behavior makes more sense in the context of section 41.16.3
> > Pixel Specification for Spaces in the Emacs manual, and it would be
> > quite the breaking change so I am hoping it was unintentional.
>
> It was intentional, since :align-to counts columns, and columns in
> Emacs continue being counted in continuation lines, they don't start
> from zero again at the point where the line wraps.  Cf current-column
> and move-to-column.  What you seem to expect would make it impossible
> to wrap lines with :align-to space display specs without losing the
> alignment when the line wraps.
>
> So this change fixed a bug, and it is therefore here to stay.  That is
> also the reason why it is not in NEWS: we don't include bug fixes
> there.