GNU bug report logs - #65015
29.1; align-to on wrapped line regression

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Axel Forsman <axelsfor@HIDDEN>; Keywords: notabug wontfix; merged with #65018, #65019, #65020, #65021, #66167; dated Wed, 2 Aug 2023 13:23:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.
Merged 65015 65018 65019 65020 65021 66167. Request was from Eli Zaretskii <eliz@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 65015 <at> debbugs.gnu.org:


Received: (at 65015) by debbugs.gnu.org; 3 Aug 2023 11:32:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 03 07:32:34 2023
Received: from localhost ([127.0.0.1]:50979 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qRWZF-0001qA-Kz
	for submit <at> debbugs.gnu.org; Thu, 03 Aug 2023 07:32:34 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:48608)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qRWZD-0001pw-Bc
 for 65015 <at> debbugs.gnu.org; Thu, 03 Aug 2023 07:32:31 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1qRWZ8-0008Vd-2j; Thu, 03 Aug 2023 07:32:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=Wd3yz+MHbUNni5YeQQbVlKPwv5bh/oirVmO1IHgp7og=; b=Zfn9KJCPgrA5
 ii68Wz1UAjiQs2R3vm3dVdz+OLZaakV8C5VsEbJiav+8GG8cJEvhelSwLXRE9QJVbfhhxedVgLFES
 4fbS4WgBMM95aPbpvnbOVabrQE8X9+FeLHg2Jz9SXHUA+S10hnv2jC77hN4NsqGGU2XiNWPVaBc/A
 p8oUqWtXdWhDmDuhniwBxb1B9TY4gcNl30+LXcf3H7b2RKbtPEzv5HD4NXQWG5ySRjpoMp+jhEnNI
 ZkMlFlBjwpajVYcG5zRSPzXy5wu+R/evJMcf/r9nJbt2mVG3EN9vxZPlCUClbT0piHxh0Ryh1938A
 aKCzRYZwE4GejlzArF5GcQ==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1qRWZ5-0007hd-1y; Thu, 03 Aug 2023 07:32:23 -0400
Date: Thu, 03 Aug 2023 14:32:31 +0300
Message-Id: <834jlgxsxc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Axel Forsman <axelsfor@HIDDEN>
In-Reply-To: <CAPt4RUqp_yecB8dyuSNk=vv8z+7V10=3WM9YmkO=a2PrRJp8BQ@HIDDEN>
 (message from Axel Forsman on Thu, 3 Aug 2023 12:48:26 +0200)
Subject: Re: bug#65015: 29.1; align-to on wrapped line regression
References: <CAPt4RUrz1KQQsH766Fbn6_+k32z=wsv7aQQ25NgxMAGTfEoOPQ@HIDDEN>
 <83jzudzewi.fsf@HIDDEN>
 <CAPt4RUq2fHOMMjc7akoEF0oLREwGOHR8CHsaEvQUii7PD_G4qg@HIDDEN>
 <837cqcznd1.fsf@HIDDEN>
 <CAPt4RUqp_yecB8dyuSNk=vv8z+7V10=3WM9YmkO=a2PrRJp8BQ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 65015
Cc: 65015 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Axel Forsman <axelsfor@HIDDEN>
> Date: Thu, 3 Aug 2023 12:48:26 +0200
> Cc: 65015 <at> debbugs.gnu.org
> 
> > Well, it doesn't really say what HPOS is.  I have clarified it now,
> > thanks.
> 
> The docstring of compute-motion already uses HPOS to signify the
> horizontal position relative to the visual left edge of the text area.
> I have not read your change yet, but please use COL for the value
> of :align-to instead of HPOS to avoid overloading terminology.

That would be sub-optimal, since HPOS can also be a pixel-wise
specification.

> I read into the fact that HPOS is already defined elsewhere and that it
> takes millimeter-values, and took it as a pixel x-offset from the current
> left edge of the text area. Is that really so outlandish?

Not outlandish, no.  Just inconsistent with the rest of the behavior
when text alignment is required.  The :align-to alignment should work
as expected, i.e. align the text in the same manner, when the window
width changes, when lines are truncated or wrapped, and when truncated
lines are hscrolled.  If the :align-to argument is measured from the
visual beginning of a screen line, this can never work, don't you
agree?

> > The above just makes no sense in wrapped lines, that's all.
> 
> Why do you feel the need to paint me as an idiot?

Whatever made you say that, I wonder?  When I say "makes no sense", I
mean it makes no sense to me.

I guess we interpret the geometries of the Emacs lines very
differently if doing that in wrapped lines makes sense to you.

> Under the semantics imposed by HPOS being as described in the
> compute-motion docstring, the previous behavior is just what anyone
> would expect. Clearly it does make sense.

It does make sense in other contexts, but not in the context of
aligning text that should hold when the window dimensions change and
horizontal scrolling is used.  The idea of :align-to is to keep the
text aligned in those circumstances.  Think, for example, about
tabulated-list-mode which is used by quite a few Emacs features: it
uses :align-to to align columns in a table-like display, and that
display should not become messed up when the window is hscrolled or
changes its width.

This is the kind of applications that :align-to is used for, and they
must be supported correctly.

> Pardon my persistence, but would it be possible to reintroduce the old
> behavior under a new space spec property name, to give everyone (read:
> me) a clear upgrade path? Evidently it was useful.

A new display spec would be possible, especially if the problems the
pre-29 implementation caused are not considered important (e.g., what
do you expect to happen when the window is hscrolled?).  But someone
will have to write the code and document it.

> > AFAIU, to adapt to this change, your code will have to call
> > current-column to compute the adjustment of the value you pass to
> > :align-to.
> 
> Well yeah, but if that is now what the best implementation has to do, then
> that is clearly less than satisfactory.

Why is it not satisfactory?  The calculation is quite simple, IIUC.

> I think overlay popups are an important use case for everyone using
> Emacs text-frames.

FTR: I have nothing against overlay popups.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#65015; Package emacs. Full text available.

Message received at 65015 <at> debbugs.gnu.org:


Received: (at 65015) by debbugs.gnu.org; 3 Aug 2023 10:48:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 03 06:48:52 2023
Received: from localhost ([127.0.0.1]:50944 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qRVsu-0006TY-TD
	for submit <at> debbugs.gnu.org; Thu, 03 Aug 2023 06:48:52 -0400
Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]:62738)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <axelsfor@HIDDEN>) id 1qRVsp-0006T9-Om
 for 65015 <at> debbugs.gnu.org; Thu, 03 Aug 2023 06:48:47 -0400
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-99c10ba30afso417901666b.1
 for <65015 <at> debbugs.gnu.org>; Thu, 03 Aug 2023 03:48:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1691059718; x=1691664518;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:from:to:cc:subject:date
 :message-id:reply-to;
 bh=TINGi0Hfr7FWwxFOz5ffHa+n9wA7hytqBgghggk1ID8=;
 b=RSP2lZMHeU+AeNPMbNZO6TqxfRoSaAUTje8k/m7ha/NnCcHqFLSXZjwXUywoyYevub
 ahb+no0f9IAaipBPkXVERu5E+M9bkCSoIbWV6aRZA4El8grfcP9wCDDzESH2gX3pq4UE
 Ahj7ftw4b/CUZwHJcHi2ALx49qVIK5tiQ+T/O7HUWw10yEY5ZXobxB7xyF0RWcK98mQ1
 6B3rYGUglytTyqsFtP34OKaDLQz+yiwU14qTNiSKubswyrd18gd7tJYsMiBxSbEreAWA
 drJntwPYYf/kFnWcTfh43koZaupeZHRBRaZcWF4mi94Z2KXew/QrI4H2nfxNH9wbShUD
 gThw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1691059718; x=1691664518;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=TINGi0Hfr7FWwxFOz5ffHa+n9wA7hytqBgghggk1ID8=;
 b=cANDln9i7nZUjoMwjdPCAwpHSNX4UmCa7wER4X3QbPiGFH3O2soNv/LAJG5pl5CFBS
 4WW0+SQ0nS4zBbx5P4QGKF08bQG3m8fgHaoK4vu7PLoQJo+gS56m1ajBOuPkOkYJMrqx
 7fsddXOBJWiNyLLr5Jh1juAZz62NIBefc1MZQPbK3XgM64RCts0PJcd7BMSN6DA6kKOw
 a5mhFMlBze4RN4GPROfVExiC12OZh/G765DXnc09Uaex0Wl4raut1KQJ3DnPsgKxOxz7
 lVwtUsbQHODeHeJCsrU1xMt7rWajwIgEQpCWUEhxjxe7hjKLRTEihWcX1VMkUWNbdwRo
 +O7w==
X-Gm-Message-State: ABy/qLa5v4wYGvwvCdALlXfmCjChUHi6BdSYtzfdFLk6arTKWShaLEt+
 BKcC7jES3wLSP9J1a2F5kQLFMQ/XGYKbl0RC3gE=
X-Google-Smtp-Source: APBJJlHsljrVsAfoHkYaYhwFeQ9aQ3sSAB6R6y3R1Xh9R1DVMyB6PhwH/4WWwKNduCJb7nDDjd+qrCzQ/bAf78cNaFU=
X-Received: by 2002:a17:907:760d:b0:99b:cdfd:fb44 with SMTP id
 jx13-20020a170907760d00b0099bcdfdfb44mr9981799ejc.9.1691059717765; Thu, 03
 Aug 2023 03:48:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAPt4RUrz1KQQsH766Fbn6_+k32z=wsv7aQQ25NgxMAGTfEoOPQ@HIDDEN>
 <83jzudzewi.fsf@HIDDEN>
 <CAPt4RUq2fHOMMjc7akoEF0oLREwGOHR8CHsaEvQUii7PD_G4qg@HIDDEN>
 <837cqcznd1.fsf@HIDDEN>
In-Reply-To: <837cqcznd1.fsf@HIDDEN>
From: Axel Forsman <axelsfor@HIDDEN>
Date: Thu, 3 Aug 2023 12:48:26 +0200
Message-ID: <CAPt4RUqp_yecB8dyuSNk=vv8z+7V10=3WM9YmkO=a2PrRJp8BQ@HIDDEN>
Subject: Re: bug#65015: 29.1; align-to on wrapped line regression
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 65015
Cc: 65015 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> Well, it doesn't really say what HPOS is.  I have clarified it now,
> thanks.

The docstring of compute-motion already uses HPOS to signify the
horizontal position relative to the visual left edge of the text area.
I have not read your change yet, but please use COL for the value
of :align-to instead of HPOS to avoid overloading terminology. That's
my suggestion at least. (Though vertical-motion also talks about
COLS in the HPOS sense, but it is at least clear about its interpretation.)

> What else can it be?

I read into the fact that HPOS is already defined elsewhere and that it
takes millimeter-values, and took it as a pixel x-offset from the current
left edge of the text area. Is that really so outlandish?

> The above just makes no sense in wrapped lines, that's all.

Why do you feel the need to paint me as an idiot? Under the semantics
imposed by HPOS being as described in the compute-motion docstring,
the previous behavior is just what anyone would expect. Clearly it does
make sense.

> The change was the result of fixing bug#56176, although there isn't
> much of discussion there, and the situation didn't involve
> continuation lines, it involved horizontal scrolling and line
> truncation.  But the behavior should be consistent; in particular,
> when a line is hscrolled, it would be wrong to reset :align-to to
> count from the visual left edge of the line on display, instead of
> from the (hidden) beginning of line.
> [...]
> We could perhaps consider some changes in this
> area, but to make any such changes, we'd need a consistent idea of
> behavior that covers line continuation, line truncation, and
> horizontal scrolling, and is at least in some sense consistent with
> current-column.  TBH, I don't believe something like this is possible,
> unless we keep the behavior of Emacs 29.

To be clear, I think tying :align-to to columns (as in current-column) is a
perfectly fine choice, and there is nothing that needs changing to that end=
.
However I do not agree that the previous behavior was necessarily a bug.
Pardon my persistence, but would it be possible to reintroduce the old
behavior under a new space spec property name, to give everyone (read:
me) a clear upgrade path? Evidently it was useful.

> AFAIU, to adapt to this change, your code will have to call
> current-column to compute the adjustment of the value you pass to
> :align-to.

Well yeah, but if that is now what the best implementation has to do, then
that is clearly less than satisfactory. I think overlay popups are an impor=
tant
use case for everyone using Emacs text-frames.


/Axel Forsman

On Thu, Aug 3, 2023 at 7:49=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote:
>
> > From: Axel Forsman <axelsfor@HIDDEN>
> > Date: Wed, 2 Aug 2023 23:19:02 +0200
> > Cc: 65015 <at> debbugs.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.
>
> Well, it doesn't really say what HPOS is.  I have clarified it now,
> thanks.
>
> > Where does the notion that :align-to takes a column come from?
>
> What else can it be?  :align-to is used for indenting and aligning
> text, and is equivalent to using TABs, so column numbers are natural
> when doing that.  People expect current-column to agree with
> :align-to, and rightfully so.
>
> > > 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.
>
> The above just makes no sense in wrapped lines, that's all.  It only
> makes sense in lines that are narrower than the window width.
>
> > Could you please link to the discussion where the old behavior was
> > termed a bug so I can read up?
>
> The change was the result of fixing bug#56176, although there isn't
> much of discussion there, and the situation didn't involve
> continuation lines, it involved horizontal scrolling and line
> truncation.  But the behavior should be consistent; in particular,
> when a line is hscrolled, it would be wrong to reset :align-to to
> count from the visual left edge of the line on display, instead of
> from the (hidden) beginning of line.
>
> > because just from reading the Emacs Lisp manual I am not so sure I
> > agree.
>
> It's okay to disagree, but my opinion on this is quite firm.
>
> > 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 reverte=
d?
>
> Reverting the change is out of the question, because it fixed a real
> bug, see bug#56176.  We could perhaps consider some changes in this
> area, but to make any such changes, we'd need a consistent idea of
> behavior that covers line continuation, line truncation, and
> horizontal scrolling, and is at least in some sense consistent with
> current-column.  TBH, I don't believe something like this is possible,
> unless we keep the behavior of Emacs 29.
>
> > 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 righ=
t
> > xy-positions regardless of where logical line breaks were. It cannot ea=
sily
> > 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.
>
> I hear you, but building features on top of such dark corners of the
> display-engine behavior was and always will be fraught with some risk
> of breakage.
>
> AFAIU, to adapt to this change, your code will have to call
> current-column to compute the adjustment of the value you pass to
> :align-to.  Something like the below:
>
>   (save-excursion
>     (beginning-of-visual-line)
>     (or (=3D (char-before) ?\n)
>         (backward-char))
>     (current-column))
>
> will tell you what to add to the "visual-based" value of :align-to to
> get what you want.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#65015; Package emacs. Full text available.

Message received at 65015 <at> debbugs.gnu.org:


Received: (at 65015) by debbugs.gnu.org; 3 Aug 2023 05:49:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Aug 03 01:49:52 2023
Received: from localhost ([127.0.0.1]:50521 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qRRDc-0000tF-7Q
	for submit <at> debbugs.gnu.org; Thu, 03 Aug 2023 01:49:52 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:36652)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qRRDY-0000sz-Ht
 for 65015 <at> debbugs.gnu.org; Thu, 03 Aug 2023 01:49:50 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1qRRDQ-0000RR-2U; Thu, 03 Aug 2023 01:49:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=cSSgAB2G/+PknJapk02UQ+pMTuKDgjOBeyvBGY4g+uU=; b=klNHQ3X0LXm5
 +eeQcep9GIncmMPaCxF5TgZF2y5IOegQZwrXiGzqoxcGDF+szdTJDWlalvgMthzIdcx2gkm5vUyyo
 ghU8pZgVUHEWhla9LNxs9DKRkL9KamfOtVk/LbaAJ9VeMd5bY4B+E4+dCUJ3AvMEbHLSMpZBYiFbF
 Dhh3WIVy2iH1jYnjcOQ+J8HjR1V5QqMWTk/gctHXrhVMJ6FQ9Czke1tjt4cOx2mIOMDjQ4VG4piu+
 8f3pLSqSidXUfu3xcevK3CEnvvKQcKY4AtJE7qCj/Ns8/jAha1u9H+7Z4T5fwPFN2nIWYpLcBCUIT
 6F+x6bd1fRKtRbe9JWvTdA==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1qRRDO-0007k3-4j; Thu, 03 Aug 2023 01:49:39 -0400
Date: Thu, 03 Aug 2023 08:49:46 +0300
Message-Id: <837cqcznd1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Axel Forsman <axelsfor@HIDDEN>
In-Reply-To: <CAPt4RUq2fHOMMjc7akoEF0oLREwGOHR8CHsaEvQUii7PD_G4qg@HIDDEN>
 (message from Axel Forsman on Wed, 2 Aug 2023 23:19:02 +0200)
Subject: Re: bug#65015: 29.1; align-to on wrapped line regression
References: <CAPt4RUrz1KQQsH766Fbn6_+k32z=wsv7aQQ25NgxMAGTfEoOPQ@HIDDEN>
 <83jzudzewi.fsf@HIDDEN>
 <CAPt4RUq2fHOMMjc7akoEF0oLREwGOHR8CHsaEvQUii7PD_G4qg@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 65015
Cc: 65015 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Axel Forsman <axelsfor@HIDDEN>
> Date: Wed, 2 Aug 2023 23:19:02 +0200
> Cc: 65015 <at> debbugs.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.

Well, it doesn't really say what HPOS is.  I have clarified it now,
thanks.

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

What else can it be?  :align-to is used for indenting and aligning
text, and is equivalent to using TABs, so column numbers are natural
when doing that.  People expect current-column to agree with
:align-to, and rightfully so.

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

The above just makes no sense in wrapped lines, that's all.  It only
makes sense in lines that are narrower than the window width.

> Could you please link to the discussion where the old behavior was
> termed a bug so I can read up?

The change was the result of fixing bug#56176, although there isn't
much of discussion there, and the situation didn't involve
continuation lines, it involved horizontal scrolling and line
truncation.  But the behavior should be consistent; in particular,
when a line is hscrolled, it would be wrong to reset :align-to to
count from the visual left edge of the line on display, instead of
from the (hidden) beginning of line.

> because just from reading the Emacs Lisp manual I am not so sure I
> agree.

It's okay to disagree, but my opinion on this is quite firm.

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

Reverting the change is out of the question, because it fixed a real
bug, see bug#56176.  We could perhaps consider some changes in this
area, but to make any such changes, we'd need a consistent idea of
behavior that covers line continuation, line truncation, and
horizontal scrolling, and is at least in some sense consistent with
current-column.  TBH, I don't believe something like this is possible,
unless we keep the behavior of Emacs 29.

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

I hear you, but building features on top of such dark corners of the
display-engine behavior was and always will be fraught with some risk
of breakage.

AFAIU, to adapt to this change, your code will have to call
current-column to compute the adjustment of the value you pass to
:align-to.  Something like the below:

  (save-excursion
    (beginning-of-visual-line)
    (or (= (char-before) ?\n)
        (backward-char))
    (current-column))

will tell you what to add to the "visual-based" value of :align-to to
get what you want.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#65015; Package emacs. Full text available.

Message received at 65015 <at> debbugs.gnu.org:


Received: (at 65015) by debbugs.gnu.org; 2 Aug 2023 21:19:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 02 17:19:22 2023
Received: from localhost ([127.0.0.1]:50207 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qRJFZ-0003o4-Gk
	for submit <at> debbugs.gnu.org; Wed, 02 Aug 2023 17:19:21 -0400
Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]:53693)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <axelsfor@HIDDEN>) id 1qRJFY-0003nr-1U
 for 65015 <at> debbugs.gnu.org; Wed, 02 Aug 2023 17:19:20 -0400
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-2b9f48b6796so3573221fa.3
 for <65015 <at> debbugs.gnu.org>; Wed, 02 Aug 2023 14:19:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1691011154; x=1691615954;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:from:to:cc:subject:date
 :message-id:reply-to;
 bh=SbjzFq+nOTG6CKyYf9ga8bkaGQszEwVt3H4tgDtXt5U=;
 b=PO3HfE7Bd431AycBJY4mx2wnSeFdq+Z2UVpK7tVOnR7rC29vaO9DqVOT8ZSaz0c48a
 vPYOm1zJi98KH7r7U/4E0jRKEZMjlWbMEwuxB1zETBaeBGxR9oJFC6u1aLr3i+6ZmVAx
 M24wP7V+3iUX8MQkLsfQim6cleaMzJ1IS+W16D2Rb3uSOCcoCYCiLG6xmcKlFqbpdNRl
 mJRHoeJX9kl0vyOKy6MWzoGHH8a07asl9v11O53RdOHF0bgVa9UrAJln7/7AVurEDmPp
 rgHQKsro5RQFglQodhsXuygDdTwPc9x9RTSRTI/EhY5ZOCo/zP91wCADfML3arUN0mXS
 8LaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1691011154; x=1691615954;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=SbjzFq+nOTG6CKyYf9ga8bkaGQszEwVt3H4tgDtXt5U=;
 b=Z4JzsmGv9eRfCI/q5tY/6Buv4aUYNgtUQmLr2SosuNFpTK4txWUCtYTRfZz68+VClJ
 5cblOFMEWqYxp4JDND6/XleL4/1882x1IplfX2H0HB+NsnU+fIMEIVIs5bE8YbsHJ+Va
 Trq+No9d2SRlYBlP6aGuR39oNv5eACd5BQr4zG61ybkon5rdi4jyjWqxN2pAkmip/3HT
 nB/H98/P2zL1eoTEEMNt/RwVi5dT5VvND+FjKEk7iUc0RabnP0Q/ewPX7KhymEkPZcLp
 3gF/tHPtP3W+3kb6xUMYOULe18m+7XlEqgKIwthsLmuKlmjLTXxpvYPj6BLYCgQKQoiq
 Fhag==
X-Gm-Message-State: ABy/qLZJ65dEIXzZnMH2pk7XrldzLVppVojOyYwE9IiwLbrhnx2vpA2Q
 WShr5ELasxELZrAAfS5jVxW2gdgqHoQ9ZIuRAuc=
X-Google-Smtp-Source: APBJJlERPjSsLKQZ8VZLOjGDL0fzkyMRyn5CSWxnICWVJaM4IqK7tIuNO6PjoFOotwUKHSiTcSWxzrhamIpjtgP56uw=
X-Received: by 2002:a2e:870b:0:b0:2b6:eefc:3e4f with SMTP id
 m11-20020a2e870b000000b002b6eefc3e4fmr5945822lji.21.1691011153694; Wed, 02
 Aug 2023 14:19:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAPt4RUrz1KQQsH766Fbn6_+k32z=wsv7aQQ25NgxMAGTfEoOPQ@HIDDEN>
 <83jzudzewi.fsf@HIDDEN>
In-Reply-To: <83jzudzewi.fsf@HIDDEN>
From: Axel Forsman <axelsfor@HIDDEN>
Date: Wed, 2 Aug 2023 23:19:02 +0200
Message-ID: <CAPt4RUq2fHOMMjc7akoEF0oLREwGOHR8CHsaEvQUii7PD_G4qg@HIDDEN>
Subject: Re: bug#65015: 29.1; align-to on wrapped line regression
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 65015
Cc: 65015 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> 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=E2=80=AFPM Eli Zaretskii <eliz@HIDDEN> wrote:
>
> > From: Axel Forsman <axelsfor@HIDDEN>
> > 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#65015; Package emacs. Full text available.
Merged 65015 65018 65019 65020 65021. Request was from Eli Zaretskii <eliz@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 65015 <at> debbugs.gnu.org:


Received: (at 65015) by debbugs.gnu.org; 2 Aug 2023 14:40:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 02 10:40:17 2023
Received: from localhost ([127.0.0.1]:49939 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qRD1M-0007lV-UP
	for submit <at> debbugs.gnu.org; Wed, 02 Aug 2023 10:40:17 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:49858)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qRD1K-0007lB-ST
 for 65015 <at> debbugs.gnu.org; Wed, 02 Aug 2023 10:40:15 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1qRD1F-0001CQ-L3; Wed, 02 Aug 2023 10:40:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=wJp5Eb+weo46wOesQxAqdtv19kuTzvLtD6wH3O5Xc/g=; b=cVGlNVsNkNtp
 i98lrUTLk/lYSPGhy2FeKj8sGspigulGgSBTZc+fribzHNB+JLk60yiVdizJZwNcVD/dXv7a7Ahrm
 wrR/EmmPZiW+j4GHbbK9ZXZGlkS0eKAlqBDiFJiOOfehXs/I2qtEeLURacQt1SNVh9dKLPtavYrVQ
 KYgJFTj+FkDA56b++SDWgWvHL4VDcV+TM4f6sL4u66nsHyz5OJpbcwbMI1DfMpKo8a0y54aoyCsAp
 g5MzhfWOy6RbJundcBPgzfkWIpU39wBl6XUdnAI7kvrE784YQL2TU1IF9doQBdxXyY9n/I9MDZKb0
 GNMDYmWgKPuFrzsiEy57sA==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1qRD1C-0000zO-Fd; Wed, 02 Aug 2023 10:40:07 -0400
Date: Wed, 02 Aug 2023 17:40:13 +0300
Message-Id: <83jzudzewi.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Axel Forsman <axelsfor@HIDDEN>
In-Reply-To: <CAPt4RUrz1KQQsH766Fbn6_+k32z=wsv7aQQ25NgxMAGTfEoOPQ@HIDDEN>
 (message from Axel Forsman on Wed, 2 Aug 2023 15:22:35 +0200)
Subject: Re: bug#65015: 29.1; align-to on wrapped line regression
References: <CAPt4RUrz1KQQsH766Fbn6_+k32z=wsv7aQQ25NgxMAGTfEoOPQ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 65015
Cc: 65015 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Axel Forsman <axelsfor@HIDDEN>
> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#65015; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 2 Aug 2023 13:22:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 02 09:22:59 2023
Received: from localhost ([127.0.0.1]:49203 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qRBoZ-0005UG-6K
	for submit <at> debbugs.gnu.org; Wed, 02 Aug 2023 09:22:59 -0400
Received: from lists.gnu.org ([2001:470:142::17]:60158)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <axelsfor@HIDDEN>) id 1qRBoX-0005Tj-CE
 for submit <at> debbugs.gnu.org; Wed, 02 Aug 2023 09:22:57 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <axelsfor@HIDDEN>)
 id 1qRBoS-0001aa-29
 for bug-gnu-emacs@HIDDEN; Wed, 02 Aug 2023 09:22:52 -0400
Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <axelsfor@HIDDEN>)
 id 1qRBoQ-00087D-8d
 for bug-gnu-emacs@HIDDEN; Wed, 02 Aug 2023 09:22:51 -0400
Received: by mail-ej1-x635.google.com with SMTP id
 a640c23a62f3a-99bf1f632b8so801332366b.1
 for <bug-gnu-emacs@HIDDEN>; Wed, 02 Aug 2023 06:22:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1690982568; x=1691587368;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=Y1Ri76yctVdAOG8I3WP0mb9mKHWuMciWi6MwZltJHqA=;
 b=TjfdNN7U7KtMdZn9QV8+GTiW2eMHxJ8kzcBYxE2XSEZs+JVxwpL44tnWvwQW/SOw13
 WABZuA7SE5O8QB1uAb19y5Ie93WYxZuw9ZQsAQEyp7KXu7QLpV1fYoiq3jQEM69U6zYc
 WN3w/3IFz238QdZU1G09bu+zs+a+kSvrie+mYyur8e2ZXegjSTkjrIy6Q0a+9bbvZ/Ww
 vvs7AkNdVx5p3O+tSuc8PaqlqaUAqf4mZa6Fq5oIH+sBwxi7RXhW1bj2trgqGPXNwTaX
 d1Q6W1kr5ztApoVn1NYECy96zUVVHmrN3+Cawi2mc5iGtyJyfic9rCISC0rj/IFVtjZV
 izZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1690982568; x=1691587368;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=Y1Ri76yctVdAOG8I3WP0mb9mKHWuMciWi6MwZltJHqA=;
 b=lerVSC2nh27cHN4F11N3IsO1SGOnBx3PxpKT4o9KtHNH2XyN+Hxz9dV8AR7sNwGWED
 gkBqmcN6LexylEa26nDb9hjm1IP8SH8jzBQVbG0zMi9m14OhSbZOS6rkfREj0PiY2Npz
 /K5qdnSyj/DYz60EbpVtKOxQNdpb42M/a6ehdCdOWldOjJB+sGSMVw5NUODR8fJfzDRh
 DLYNx/XhEEt2PZRBxKUNTEtvMWGwayiitKCLKDtrfjtAhkwI/WR+4incwZCBAOfQCywi
 hxec7TDUIpn1afoMxvR3IvFokj+gxqYXCdAhI9m/etnvWHvg4+MH64v3428mdIVa00qm
 qbVg==
X-Gm-Message-State: ABy/qLYon6M99Fy51B9u2wNCULLYA8ny2jQaxIQkPwS40+WflJTXNAf0
 DLvKakpbPeXBsFuRvuu85EbKkxY/ZBfup3jd8ejXcOyH2i1nww==
X-Google-Smtp-Source: APBJJlHRPl0oIl3tArPqJc74IVME8MzagMbUhkTPVuP4Tl/0F9KvJhg44d2Y4eCF9Kn70bOLnTNymerpt4fTnsozAps=
X-Received: by 2002:a17:907:2c77:b0:997:caf0:9945 with SMTP id
 ib23-20020a1709072c7700b00997caf09945mr4839275ejc.12.1690982567447; Wed, 02
 Aug 2023 06:22:47 -0700 (PDT)
MIME-Version: 1.0
From: Axel Forsman <axelsfor@HIDDEN>
Date: Wed, 2 Aug 2023 15:22:35 +0200
Message-ID: <CAPt4RUrz1KQQsH766Fbn6_+k32z=wsv7aQQ25NgxMAGTfEoOPQ@HIDDEN>
Subject: 29.1; align-to on wrapped line regression
To: bug-gnu-emacs@HIDDEN
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=2a00:1450:4864:20::635;
 envelope-from=axelsfor@HIDDEN; helo=mail-ej1-x635.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

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.


Kind regards
Axel Forsman


In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu)
Repository revision: emacs-29.1
Repository branch: master
System Description: NixOS 23.05 (Stoat)

Configured using:
 'configure
 --prefix=/nix/store/whazydpl0yj8i03aapsd2cyry70mng55-emacs-unstable-29.1-nox
 --disable-build-details --with-modules --with-gif=no --with-jpeg=no
 --with-png=no --with-tiff=no --with-x=no --with-xpm=no
 --with-native-compilation --with-tree-sitter'

Configured features:
DBUS GMP GNUTLS GPM JSON LIBSELINUX LIBSYSTEMD LIBXML2 MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER SECCOMP SOUND SQLITE3 THREADS
TREE_SITTER ZLIB

Important settings:
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LANG: sv_SE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  undo-tree-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  hotfuzz-vertico-mode: t
  vertico-mode: t
  xclip-mode: t
  evil-mode: t
  evil-local-mode: t
  electric-pair-mode: t
  delete-selection-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/run/current-system/sw/share/emacs/site-lisp/site-start hides
/nix/store/whazydpl0yj8i03aapsd2cyry70mng55-emacs-unstable-29.1-nox/share/emacs/site-lisp/site-start

Features:
(shadow sort mail-extr emacsbug mule-util hotfuzz-module notmuch
notmuch-tree notmuch-jump notmuch-hello image wid-edit notmuch-show
notmuch-print notmuch-crypto notmuch-mua notmuch-message notmuch-draft
notmuch-maildir-fcc notmuch-address notmuch-company notmuch-parser
notmuch-wash diff-mode easy-mmode coolj goto-addr icalendar diary-lib
diary-loaddefs cal-menu calendar cal-loaddefs notmuch-tag crm
notmuch-lib notmuch-version notmuch-compat hl-line message sendmail
yank-media dired dnd dired-loaddefs rfc822 mml mailabbrev mail-utils
gmm-utils mailheader mm-view mml-smime mml-sec epa derived epg rfc6068
epg-config gnus-util text-property-search time-date smime password-cache
gnutls puny dig mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 mm-util ietf-drums mail-prsvr term/tmux term/xterm xterm
lua-mode-autoloads nix-mode-autoloads julia-mode-autoloads
cmake-mode-autoloads yaml-mode-autoloads haskell-mode-autoloads
typescript-mode-autoloads markdown-mode-autoloads rust-mode-autoloads
mytheme-theme ws-butler-autoloads rmsbolt-autoloads corfu-autoloads
yasnippet undo-tree diff queue yasnippet-autoloads transient format-spec
eieio eieio-core magit-autoloads magit-section-autoloads
git-commit-autoloads with-editor-autoloads dash-autoloads
xterm-color-autoloads devdocs-autoloads hotfuzz vertico compat
hotfuzz-autoloads vertico-autoloads compat-autoloads xclip
xclip-autoloads evil evil-keybindings evil-integration evil-maps
evil-commands reveal evil-jumps evil-command-window evil-search evil-ex
evil-types evil-macros evil-repeat evil-states evil-core byte-opt comp
regexp-opt comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode tool-bar advice evil-common thingatpt rect evil-vars ring
edmacro kmacro undo-tree-autoloads queue-autoloads evil-autoloads
goto-chg-autoloads pcase elec-pair delsel autorevert filenotify
cl-loaddefs cl-lib ekipage bytecomp byte-compile rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify multi-tty make-network-process native-compile
emacs)

Memory information:
((conses 16 623896 226463)
 (symbols 48 15703 10)
 (strings 32 85936 57749)
 (string-bytes 1 4096111)
 (vectors 16 33101)
 (vector-slots 8 543541 137525)
 (floats 8 64 333)
 (intervals 56 62415 18186)
 (buffers 984 13))




Acknowledgement sent to Axel Forsman <axelsfor@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#65015; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sat, 23 Sep 2023 10:15:01 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.