bug#27525: 25.1; Line wrapping of bidi paragraphs

[Itai Berli <itai.berli@gmail.com>]

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

Eli, in different bug report, namely 27526, I recently wrote the following
remark:

> the line-wrapping bug is still a major annoyance, at best, and until it
is fixed, Emacs cannot claim to be Unicode compliant.

to which you replied:

> I disagree, as I already said many times.

You do agree, though, that Emacs does not conform to the Unicode
Bidirectional Algorithm as specified in the Unicode Standard Annex #9.
After all, the following paragraph appears in the bidi code itself (
http://git.savannah.gnu.org/cgit/emacs.git/tree/src/bidi.c):

   Note that, because reordering is implemented below the level in
   xdisp.c that breaks glyphs into screen lines, we are violating
   paragraph 3.4 of UAX#9. which mandates that line breaking shall be
   done before reordering each screen line separately.

So the only thing you disagree with me is that non-conformance to the
Unicode Bidirectional Algorithm is tantamount to non-conformance to the
Unicode Standard. Well, this disagreement is easily settled by reading
article C12 'Bidirectional Text' of section 3.2 'Conformance Requirements'
of the Unicode Standard:

A process that displays text containing supported right-to-left characters
or embedding codes shall display all visible representations of characters
(excluding format characters) in the same order as if the Bidirectional
Algorithm had been applied to the text, unless tailored by a higher-level
protocol as permitted by the specification.

* The Bidirectional Algorithm is specified in Unicode Standard Annex #9,
“Uni- code Bidirectional Algorithm.”


On Sun, Jul 9, 2017 at 9:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
> > Cc: 27525@debbugs.gnu.org,  itai.berli@gmail.com
> > Date: Sun, 09 Jul 2017 20:17:41 +0200
> >
> > >> From: Richard Stallman <rms@gnu.org>
> > >> It might be good if Emacs could refill lines automatically the way
> > >> some other ediors do.
> >
> > Eli Zaretskii writes:
> > > We already have that: "M-x visual-line-mode RET".
> >
> > JFTR, even that does not help in this case.  With visual-line-mode the
> > order of the lines is still wrong with the text that the OP gave.
>
> Of course.  It isn't supposed to help.  From the POV of the display
> engine, visual-line-mode is just a fancy kind of producing
> continuation lines, so all the problems you see with continued lines
> will still be there in visual-line-mode.
>

[-- Attachment #2: Type: text/html, Size: 4287 bytes --]