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

[Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>]

Eli Zaretskii writes:
> Does the patch below fix the problem?

Sorry, no, no change here with that. 


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.  But
Emacs' line wrap is only active with truncate-lines=nil, and
truncate-lines is set to t in eww-mode.  When I set truncate-lines=nil
in shr-insert-document the bug does actually go away.  I do not know why
truncate-lines was set to t in the first place, though, and where that
may have other consequences.


I'm wondering why this bug depends on RTL layout.  I tried my test case
without dir=rtl and with "abc" as text, but that works fine, so RTL
really is a factor.

But that's not right, is it?  Conceptually, the linebreak opportunities
should be the same regardless of the paragraph direction, RTL or LTR.
For mixed text the visual order of the runs for should be different for
RTL paragraphs, but even than the length of the lines and where they are
broken should not change.  Line breaks should be found according to
logical ordering.  Let's say I have:

   aaa bbb אאא בבב

If I have to break it before the last word, I want to get:

   aaa bbb אאא
   בבב

And indeed, fill-paragraph does the right thing with this example.

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?  At least
Emacs default wrapping behaviour seems not directly usable as a basis
for filling paragraphs correctly.