bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41506: 28.0.50; RTL problem


From: Pip Cet
Subject: bug#41506: 28.0.50; RTL problem
Date: Tue, 2 Jun 2020 10:17:55 +0000

On Sun, May 24, 2020 at 2:46 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Sun, 24 May 2020 13:05:17 +0000
> >
> > I'm surprised by the way vanilla Emacs behaves when given RTL input:
> >
> > Recipe:
> > emacs -Q hebrew.txt
> >
> > hebrew.txt contains (or should contain!) two newlines followed by the
> > Hebrew word Ivri, punctuated, followed by another single newline.
> >
> > Expected result:
> > right-aligned text
> >
> > Actual result:
> > left-aligned text
> >
> > Is that a bug, or is there something I don't understand?
>
> It's a bug, but one that's very tricky to fix, AFAIR.  If you insert
> or delete a single character, the display becomes correct.

The attached patch seems to avoid the problem, but I'm sure I'm
missing something.

The comment says "don't do that at BEGV since then we are potentially
in a new paragraph that doesn't yet exist". I'm failing to make sense
of that, and the commit (5e65aec01a9bc5a147e492f11dd0115c98bedef4)
isn't too helpful either: "Fix bidi iteration near BEGV and ZV."

I suspect what might have been meant is that narrowing an LTR
paragraph to a line containing STRONG_R text shouldn't result in RTL
display, but it does...

Attachment: 0001-Bidi-patch.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]