unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Axel Forsman <axelsfor@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 65015@debbugs.gnu.org
Subject: bug#65015: 29.1; align-to on wrapped line regression
Date: Wed, 2 Aug 2023 23:19:02 +0200	[thread overview]
Message-ID: <CAPt4RUq2fHOMMjc7akoEF0oLREwGOHR8CHsaEvQUii7PD_G4qg@mail.gmail.com> (raw)
In-Reply-To: <83jzudzewi.fsf@gnu.org>

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





  reply	other threads:[~2023-08-02 21:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-02 13:22 bug#65015: 29.1; align-to on wrapped line regression Axel Forsman
2023-08-02 14:40 ` Eli Zaretskii
2023-08-02 21:19   ` Axel Forsman [this message]
2023-08-03  5:49     ` Eli Zaretskii
2023-08-03 10:48       ` Axel Forsman
2023-08-03 11:32         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPt4RUq2fHOMMjc7akoEF0oLREwGOHR8CHsaEvQUii7PD_G4qg@mail.gmail.com \
    --to=axelsfor@gmail.com \
    --cc=65015@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).