bug#22250: 25.0.50; Eww fails to break RTL paragraph

[Eli Zaretskii <eliz@gnu.org>]

> From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
> Cc: 22250@debbugs.gnu.org,  larsi@gnus.org
> Date: Mon, 28 Dec 2015 17:40:43 +0100
> 
> Eli Zaretskii writes:
> > Does the patch below fix the problem?
> 
> Sorry, no, no change here with that. 

??? It certainly solved the problem with your original HTML file
visited with eww-open-file.  Doesn't it solve that for you?  Are you
sure you tested correctly?  And what exactly did you test?

> I looked at the code though and I noticed the call stack
> 
>   shr-fill-line
>    -> shr-vertical-motion
>       -> vertical-motion
> 
> which is used to find the line break point.  It seems the idea here is
> that Emacs' normal line wrap is used, we just go one line down, and
> vertical-motion gets us to the place where Emacs has wrapped.

No, that's not how this works, AFAIK.  (But Lars can correct me if I'm
wrong.)  What it does is go to the column where it wants to wrap and
then checks if it's at EOL.  If not, it goes back and looks for a
place to insert a newline.  Rinse, repeat.

> I'm wondering why this bug depends on RTL layout.

I'm wondering why it happens at all, after the patch I sent.  When
bidi-display-reordering is set to nil, there is no RTL layout, any
text is laid out in strict logical left-to-right order.

> I tried my test case without dir=rtl and with "abc" as text, but
> that works fine, so RTL really is a factor.

It cannot be, not when bidi-display-reordering is bound to nil.
Something else is at work there.

> If I narrow my Emacs window here, it breaks like this, though:
> 
>    aaa bbb בבב
>    אאא
> 
> So there seems to be an even bigger issue in Emacs generally?

No, this is the bidi display engine working as designed.

> At least Emacs default wrapping behaviour seems not directly usable
> as a basis for filling paragraphs correctly.

shr doesn't use the wrapping behavior, it does its own layout
calculations.