GNU bug report logs - #41506
two newlines followed by RTL text aligns left instead of right

Previous Next

Full log

Message #15 received at 41506 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41506 <at> debbugs.gnu.org
Subject: Re: bug#41506: 28.0.50; RTL problem
Date: Tue, 2 Jun 2020 10:17:55 +0000

[Message part 1 (text/plain, inline)]

On Sun, May 24, 2020 at 2:46 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> 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...

[0001-Bidi-patch.patch (text/x-patch, attachment)]

Previous Next

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