bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

In a buffer that contains bidirectional text, setting
bidi-paragraph-direction to 'left-to-right aligns the RTL text with the
left margin like the LTR text; see the first sexp below and the top
buffer in the attached screenshot.

Another alternative to get this alignment is to leave
bidi-paragraph-direction at its default value of nil and use a space
display specification with a suitable value for the :align-to property,
but this requires a calculation that seems to depend at least on the
font used and the values of `window-width' and `string-width' for the
string used (or the corresponding pixel-width values); see the second
sexp below and the middle buffer in the attached screenshot.

It's also possible to avoid this calculation and use an :align-to value
of 0 in combination with setting bidi-paragraph-direction to
'left-to-right; see the third sexp below and the bottom buffer in the
attached screenshot.  However, as the screenshot shows, this last
alternative breaks Arabic text shaping, at least for the fonts I tried
(Noto Naskh Arabic, DejaVu Sans and Amiri).  If this is not an Emacs bug
but a limitation of the current display engine or a HarfBuzz bug,
perhaps it should be noted in etc/PROBLEMS.

(let* ((a "السّلام عليكم")
       (b "Hello")
       (buf (get-buffer-create "Test1")))
  (with-current-buffer buf
    (erase-buffer)
    (setq bidi-paragraph-direction 'left-to-right)
    (insert a "\n\n" b)
    (switch-to-buffer buf)))

(let* ((a "السّلام عليكم")
       (wa (+ (- (window-width) (string-width a)) 0.75))
       (b "Hello")
       (buf (get-buffer-create "Test2")))
  (with-current-buffer buf
    (erase-buffer)
    (insert (propertize " " 'display `(space :align-to ,wa)) a "\n\n" b)
    (switch-to-buffer buf)))

(let* ((a "السّلام عليكم")
       (b "Hello")
       (buf (get-buffer-create "Test3")))
  (with-current-buffer buf
    (erase-buffer)
    (setq bidi-paragraph-direction 'left-to-right)
    (insert (propertize " " 'display `(space :align-to 0)) a "\n\n" b)
    (switch-to-buffer buf)))


[-- Attachment #2: Screenshot_2024-02-25_15-28-01.png --]
[-- Type: image/png, Size: 31934 bytes --]

[-- Attachment #3: Type: text/plain, Size: 744 bytes --]


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.18.0) of 2024-02-20 built on strobelfs2
Repository revision: d9afa1f30fdf9d00b447fea0a8343397333e172f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101009
System Description: Linux From Scratch r12.0-112

Configured using:
 'configure -C --with-xwidgets 'CFLAGS=-Og -g3'
 PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Eli Zaretskii]

> Date: Sun, 25 Feb 2024 17:22:45 +0100
> From:  Stephen Berman via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> In a buffer that contains bidirectional text, setting
> bidi-paragraph-direction to 'left-to-right aligns the RTL text with the
> left margin like the LTR text; see the first sexp below and the top
> buffer in the attached screenshot.

Yes, and that's what you should expect.  That's what
bidi-paragraph-direction set to left-to-right means: the base
paragraph direction of every paragraph in this buffer will be LTR.  If
you think this is a bug or unexpected, please tell why.

> Another alternative to get this alignment is to leave
> bidi-paragraph-direction at its default value of nil and use a space
> display specification with a suitable value for the :align-to property,
> but this requires a calculation that seems to depend at least on the
> font used and the values of `window-width' and `string-width' for the
> string used (or the corresponding pixel-width values); see the second
> sexp below and the middle buffer in the attached screenshot.

Yes, because in a RTL paragraph, columns are counted from the right
edge of the window.  So this again is the expected behavior, and if
you consider that unexpected, please explain why.

> It's also possible to avoid this calculation and use an :align-to value
> of 0 in combination with setting bidi-paragraph-direction to
> 'left-to-right;

What is the purpose of using ":align-to 0"? what do you think is the
semantics of that and your expectations?

> see the third sexp below and the bottom buffer in the
> attached screenshot.  However, as the screenshot shows, this last
> alternative breaks Arabic text shaping, at least for the fonts I tried

I will look into the shaping problem, but in general 'display' specs
do affect bidirectional display; see the end of the node "Specified
Space" in the ELisp manual.

Still, I don't think I understand what are you reporting as a bug
here.  Please clarify.

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sun, 25 Feb 2024 18:47:48 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Sun, 25 Feb 2024 17:22:45 +0100
>> From:  Stephen Berman via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> In a buffer that contains bidirectional text, setting
>> bidi-paragraph-direction to 'left-to-right aligns the RTL text with the
>> left margin like the LTR text; see the first sexp below and the top
>> buffer in the attached screenshot.
>
> Yes, and that's what you should expect.  That's what
> bidi-paragraph-direction set to left-to-right means: the base
> paragraph direction of every paragraph in this buffer will be LTR.  If
> you think this is a bug or unexpected, please tell why.

No, this is indeed what I expected (see below for elaboration).

>> Another alternative to get this alignment is to leave
>> bidi-paragraph-direction at its default value of nil and use a space
>> display specification with a suitable value for the :align-to property,
>> but this requires a calculation that seems to depend at least on the
>> font used and the values of `window-width' and `string-width' for the
>> string used (or the corresponding pixel-width values); see the second
>> sexp below and the middle buffer in the attached screenshot.
>
> Yes, because in a RTL paragraph, columns are counted from the right
> edge of the window.  So this again is the expected behavior, and if
> you consider that unexpected, please explain why.

This is also what I expected.  But it would be nice if there were an
easier way to calculate the value of :align-to (I looked in the Elisp
manual but didn't find anything that would give me the value 0.75 I
found by trial and error).

>> It's also possible to avoid this calculation and use an :align-to value
>> of 0 in combination with setting bidi-paragraph-direction to
>> 'left-to-right;
>
> What is the purpose of using ":align-to 0"? what do you think is the
> semantics of that and your expectations?

I wanted to align to the first column (0) in LTR order, for which it's
necessary set bidi-paragraph-direction to 'left-to-right.  The resulting
alignment is what I wanted and expected, but the broken shaping is not.

>> see the third sexp below and the bottom buffer in the
>> attached screenshot.  However, as the screenshot shows, this last
>> alternative breaks Arabic text shaping, at least for the fonts I tried
>
> I will look into the shaping problem, but in general 'display' specs
> do affect bidirectional display; see the end of the node "Specified
> Space" in the ELisp manual.
>
> Still, I don't think I understand what are you reporting as a bug
> here.  Please clarify.

Sorry for not being clearer in my report: the bug is the broken shaping
with the combination of setting bidi-paragraph-direction and using
:align-to; the first two examples were meant to show that using these
individually also works.  But I gather from your reply that I've
misunderstood what :align-to set to 0 means; can you enlighten me?

Steve Berman

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 69384@debbugs.gnu.org
> Date: Sun, 25 Feb 2024 18:17:35 +0100
> 
> >> Another alternative to get this alignment is to leave
> >> bidi-paragraph-direction at its default value of nil and use a space
> >> display specification with a suitable value for the :align-to property,
> >> but this requires a calculation that seems to depend at least on the
> >> font used and the values of `window-width' and `string-width' for the
> >> string used (or the corresponding pixel-width values); see the second
> >> sexp below and the middle buffer in the attached screenshot.
> >
> > Yes, because in a RTL paragraph, columns are counted from the right
> > edge of the window.  So this again is the expected behavior, and if
> > you consider that unexpected, please explain why.
> 
> This is also what I expected.  But it would be nice if there were an
> easier way to calculate the value of :align-to (I looked in the Elisp
> manual but didn't find anything that would give me the value 0.75 I
> found by trial and error).

I don't understand well enough what were you trying to achieve, so I
cannot suggest how to do that.

> >> It's also possible to avoid this calculation and use an :align-to value
> >> of 0 in combination with setting bidi-paragraph-direction to
> >> 'left-to-right;
> >
> > What is the purpose of using ":align-to 0"? what do you think is the
> > semantics of that and your expectations?
> 
> I wanted to align to the first column (0) in LTR order, for which it's
> necessary set bidi-paragraph-direction to 'left-to-right.  The resulting
> alignment is what I wanted and expected, but the broken shaping is not.

What do you mean by "first column (0) in LTR order"?  D|o you mean the
leftmost column in the visual order? something else?

> > Still, I don't think I understand what are you reporting as a bug
> > here.  Please clarify.
> 
> Sorry for not being clearer in my report: the bug is the broken shaping
> with the combination of setting bidi-paragraph-direction and using
> :align-to

OK, I will look into that when I have time.

> the first two examples were meant to show that using these
> individually also works.  But I gather from your reply that I've
> misunderstood what :align-to set to 0 means; can you enlighten me?

It's supposed to be a no-op, of course.  Exactly like in the strict
LTR unidirectional text.  What else can it mean?

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sun, 25 Feb 2024 19:35:22 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 69384@debbugs.gnu.org
>> Date: Sun, 25 Feb 2024 18:17:35 +0100
>>
>> >> Another alternative to get this alignment is to leave
>> >> bidi-paragraph-direction at its default value of nil and use a space
>> >> display specification with a suitable value for the :align-to property,
>> >> but this requires a calculation that seems to depend at least on the
>> >> font used and the values of `window-width' and `string-width' for the
>> >> string used (or the corresponding pixel-width values); see the second
>> >> sexp below and the middle buffer in the attached screenshot.
>> >
>> > Yes, because in a RTL paragraph, columns are counted from the right
>> > edge of the window.  So this again is the expected behavior, and if
>> > you consider that unexpected, please explain why.
>>
>> This is also what I expected.  But it would be nice if there were an
>> easier way to calculate the value of :align-to (I looked in the Elisp
>> manual but didn't find anything that would give me the value 0.75 I
>> found by trial and error).
>
> I don't understand well enough what were you trying to achieve, so I
> cannot suggest how to do that.

I want to display RTL text aligned with LTR text; the buffer contains
mainly LTR text.  Currently just setting bidi-paragraph-direction to
'left-to-right is sufficient for aligning at column 0, but I may want to
align to some column in the middle of the window, which I why I tried
using :align-to and found calculating the needed value cumbersome.

>> >> It's also possible to avoid this calculation and use an :align-to value
>> >> of 0 in combination with setting bidi-paragraph-direction to
>> >> 'left-to-right;
>> >
>> > What is the purpose of using ":align-to 0"? what do you think is the
>> > semantics of that and your expectations?
>>
>> I wanted to align to the first column (0) in LTR order, for which it's
>> necessary set bidi-paragraph-direction to 'left-to-right.  The resulting
>> alignment is what I wanted and expected, but the broken shaping is not.
>
> What do you mean by "first column (0) in LTR order"?  D|o you mean the
> leftmost column in the visual order? something else?

Yes, column 0 as in a buffer containing only LTR text.

>> > Still, I don't think I understand what are you reporting as a bug
>> > here.  Please clarify.
>>
>> Sorry for not being clearer in my report: the bug is the broken shaping
>> with the combination of setting bidi-paragraph-direction and using
>> :align-to
>
> OK, I will look into that when I have time.

Thanks.

>> the first two examples were meant to show that using these
>> individually also works.  But I gather from your reply that I've
>> misunderstood what :align-to set to 0 means; can you enlighten me?
>
> It's supposed to be a no-op, of course.  Exactly like in the strict
> LTR unidirectional text.  What else can it mean?

I now realize I shouldn't have used :align-to 0 for this case, since
setting bidi-paragraph-direction to 'left-to-right already gives the
desired column-0 alignment.  It's for alignment to a columns > 0 that
:align-to in combination with bidi-paragraph-direction could be useful,
if the value of :align-to were easy to use, e.g. simply to to align the
RTL text to LTR-column 20 (instead of having to do some trial-and-error
calculation).  But the broken shaping thwarts that.

Steve Berman

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 69384@debbugs.gnu.org
> Date: Sun, 25 Feb 2024 19:26:55 +0100
> 
> On Sun, 25 Feb 2024 19:35:22 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > I don't understand well enough what were you trying to achieve, so I
> > cannot suggest how to do that.
> 
> I want to display RTL text aligned with LTR text; the buffer contains
> mainly LTR text.  Currently just setting bidi-paragraph-direction to
> 'left-to-right is sufficient for aligning at column 0, but I may want to
> align to some column in the middle of the window, which I why I tried
> using :align-to and found calculating the needed value cumbersome.

Sorry, this is still too vague.  What do you mean by "RTL text aligned
with LTR text"? "aligned" in what way and sense?

How about an example of text showing what you want to do?  To avoid
strange effects of bidi reordering, please use lower-case letters to
represent LTR text and upper-case letters to represent RTL text.

> > What do you mean by "first column (0) in LTR order"?  D|o you mean the
> > leftmost column in the visual order? something else?
> 
> Yes, column 0 as in a buffer containing only LTR text.

Please don't talk about column numbers in this context, because it's
confusing: in RTL text columns are counted from the right.  "Leftmost
column", by contrast, is clear.

> >> the first two examples were meant to show that using these
> >> individually also works.  But I gather from your reply that I've
> >> misunderstood what :align-to set to 0 means; can you enlighten me?
> >
> > It's supposed to be a no-op, of course.  Exactly like in the strict
> > LTR unidirectional text.  What else can it mean?
> 
> I now realize I shouldn't have used :align-to 0 for this case, since
> setting bidi-paragraph-direction to 'left-to-right already gives the
> desired column-0 alignment.

Exactly.

> It's for alignment to a columns > 0 that :align-to in combination
> with bidi-paragraph-direction could be useful, if the value of
> :align-to were easy to use, e.g. simply to to align the RTL text to
> LTR-column 20 (instead of having to do some trial-and-error
> calculation).  But the broken shaping thwarts that.

You should be able to do that without tweaking
bidi-paragraph-direction, since :align-to can use the 'left' and
'right' positions.  For example:

  (let* ((a "السّلام عليكم")
	 (b "Hello")
	 (buf (get-buffer-create "Test3")))
    (with-current-buffer buf
      (erase-buffer)
      (insert (propertize " " 'display
                              `(space :align-to (- right 20))) a "\n\n" b)
      (switch-to-buffer buf)))

(Except that it looks like 'left' and 'right' are reversed in this
case, probably a bug.)

You can also use 'text' to stand for the width of the text-area of a
window.

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 3816 bytes --]

On Sun, 25 Feb 2024 21:45:43 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 69384@debbugs.gnu.org
>> Date: Sun, 25 Feb 2024 19:26:55 +0100
>> 
>> On Sun, 25 Feb 2024 19:35:22 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> > I don't understand well enough what were you trying to achieve, so I
>> > cannot suggest how to do that.
>> 
>> I want to display RTL text aligned with LTR text; the buffer contains
>> mainly LTR text.  Currently just setting bidi-paragraph-direction to
>> 'left-to-right is sufficient for aligning at column 0, but I may want to
>> align to some column in the middle of the window, which I why I tried
>> using :align-to and found calculating the needed value cumbersome.
>
> Sorry, this is still too vague.  What do you mean by "RTL text aligned
> with LTR text"? "aligned" in what way and sense?
>
> How about an example of text showing what you want to do?  To avoid
> strange effects of bidi reordering, please use lower-case letters to
> represent LTR text and upper-case letters to represent RTL text.

The screenshot in my first post in this bug shows the alignment I want:
the last (i.e. leftmost) character of the Arabic string occupies the
same horizontal position (in this case, the leftmost column) as the
first (i.e. leftmost) character of the English string.

>> > What do you mean by "first column (0) in LTR order"?  D|o you mean the
>> > leftmost column in the visual order? something else?
>> 
>> Yes, column 0 as in a buffer containing only LTR text.
>
> Please don't talk about column numbers in this context, because it's
> confusing: in RTL text columns are counted from the right.  "Leftmost
> column", by contrast, is clear.

Ok.

>> >> the first two examples were meant to show that using these
>> >> individually also works.  But I gather from your reply that I've
>> >> misunderstood what :align-to set to 0 means; can you enlighten me?
>> >
>> > It's supposed to be a no-op, of course.  Exactly like in the strict
>> > LTR unidirectional text.  What else can it mean?
>> 
>> I now realize I shouldn't have used :align-to 0 for this case, since
>> setting bidi-paragraph-direction to 'left-to-right already gives the
>> desired column-0 alignment.
>
> Exactly.
>
>> It's for alignment to a columns > 0 that :align-to in combination
>> with bidi-paragraph-direction could be useful, if the value of
>> :align-to were easy to use, e.g. simply to to align the RTL text to
>> LTR-column 20 (instead of having to do some trial-and-error
>> calculation).  But the broken shaping thwarts that.
>
> You should be able to do that without tweaking
> bidi-paragraph-direction, since :align-to can use the 'left' and
> 'right' positions.  For example:
>
>   (let* ((a "السّلام عليكم")
> 	 (b "Hello")
> 	 (buf (get-buffer-create "Test3")))
>     (with-current-buffer buf
>       (erase-buffer)
>       (insert (propertize " " 'display
>                               `(space :align-to (- right 20))) a "\n\n" b)
>       (switch-to-buffer buf)))
>
> (Except that it looks like 'left' and 'right' are reversed in this
> case, probably a bug.)

Thanks for the suggestion and code sample.  However, this aligns the
*first* (i.e. *rightmost*) character of the Arabic string with the
position 20 columns from the left; see the attached screenshot,
produced by the following extension of your code sample:

(let* ((a "السّلام عليكم")
       (b "Hello")
       (buf (get-buffer-create "Test3")))
  (with-current-buffer buf
    (erase-buffer)
    (insert (propertize " " 'display `(space :align-to (- right 20)))
	    a "\n\n" (make-string 20 ? ) b
            "\n12345678901234567890")
    (switch-to-buffer buf)))


[-- Attachment #2: Screenshot_2024-02-25_21-58-11.png --]
[-- Type: image/png, Size: 15426 bytes --]

[-- Attachment #3: Type: text/plain, Size: 316 bytes --]


What I want is for the leftmost character of both strings to be aligned,
and with :align-to I can't seem to do this without having to make a
fiddly calculation.

> You can also use 'text' to stand for the width of the text-area of a
> window.

I don't see how that would avoid the fiddly calculation.

Steve Berman

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 69384@debbugs.gnu.org
> Date: Sun, 25 Feb 2024 22:18:10 +0100
> 
> > Sorry, this is still too vague.  What do you mean by "RTL text aligned
> > with LTR text"? "aligned" in what way and sense?
> >
> > How about an example of text showing what you want to do?  To avoid
> > strange effects of bidi reordering, please use lower-case letters to
> > represent LTR text and upper-case letters to represent RTL text.
> 
> The screenshot in my first post in this bug shows the alignment I want:
> the last (i.e. leftmost) character of the Arabic string occupies the
> same horizontal position (in this case, the leftmost column) as the
> first (i.e. leftmost) character of the English string.

Then why not use something like this:

  (let* ((a "السّلام عليكم")
	 (b "Hello")
	 (buf (get-buffer-create "Test1")))
    (with-current-buffer buf
      (erase-buffer)
      (setq bidi-paragraph-direction 'left-to-right)
      (insert "      " a
	      "\n\n"
	      "      " b)
      (switch-to-buffer buf)))

IOW, align with spaces and TABs.

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Mon, 26 Feb 2024 14:41:32 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 69384@debbugs.gnu.org
>> Date: Sun, 25 Feb 2024 22:18:10 +0100
>> 
>> > Sorry, this is still too vague.  What do you mean by "RTL text aligned
>> > with LTR text"? "aligned" in what way and sense?
>> >
>> > How about an example of text showing what you want to do?  To avoid
>> > strange effects of bidi reordering, please use lower-case letters to
>> > represent LTR text and upper-case letters to represent RTL text.
>> 
>> The screenshot in my first post in this bug shows the alignment I want:
>> the last (i.e. leftmost) character of the Arabic string occupies the
>> same horizontal position (in this case, the leftmost column) as the
>> first (i.e. leftmost) character of the English string.
>
> Then why not use something like this:
>
>   (let* ((a "السّلام عليكم")
> 	 (b "Hello")
> 	 (buf (get-buffer-create "Test1")))
>     (with-current-buffer buf
>       (erase-buffer)
>       (setq bidi-paragraph-direction 'left-to-right)
>       (insert "      " a
> 	      "\n\n"
> 	      "      " b)
>       (switch-to-buffer buf)))
>
> IOW, align with spaces and TABs.

🤦 As so often, the obvious solution is only obvious after it's shown to
you....  Thanks.

Steve Berman

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Eli Zaretskii]

> Cc: 69384@debbugs.gnu.org
> Date: Sun, 25 Feb 2024 19:35:22 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Sorry for not being clearer in my report: the bug is the broken shaping
> > with the combination of setting bidi-paragraph-direction and using
> > :align-to
> 
> OK, I will look into that when I have time.

It's a relatively recent regression on the master branch, caused by
yours truly.  I hope I've fixed it now.

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Mon, 26 Feb 2024 19:28:09 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> Cc: 69384@debbugs.gnu.org
>> Date: Sun, 25 Feb 2024 19:35:22 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>>
>> > Sorry for not being clearer in my report: the bug is the broken shaping
>> > with the combination of setting bidi-paragraph-direction and using
>> > :align-to
>>
>> OK, I will look into that when I have time.
>
> It's a relatively recent regression on the master branch, caused by
> yours truly.  I hope I've fixed it now.

I updated and rebuilt, and confirm that with the code I posted that
resulted in broken Arabic shaping, the shaping is now correct.  Thanks!

Steve Berman

bug#69384: 30.0.50; :align-to and bidi-paragraph-direction interaction

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 69384@debbugs.gnu.org
> Date: Mon, 26 Feb 2024 22:46:50 +0100
> 
> On Mon, 26 Feb 2024 19:28:09 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> Cc: 69384@debbugs.gnu.org
> >> Date: Sun, 25 Feb 2024 19:35:22 +0200
> >> From: Eli Zaretskii <eliz@gnu.org>
> >>
> >> > Sorry for not being clearer in my report: the bug is the broken shaping
> >> > with the combination of setting bidi-paragraph-direction and using
> >> > :align-to
> >>
> >> OK, I will look into that when I have time.
> >
> > It's a relatively recent regression on the master branch, caused by
> > yours truly.  I hope I've fixed it now.
> 
> I updated and rebuilt, and confirm that with the code I posted that
> resulted in broken Arabic shaping, the shaping is now correct.  Thanks!

Thanks, I'm therefore closing this bug.