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 19:15:50 +0100
> 
> >> Eli Zaretskii writes:
> >> > Does the patch below fix the problem?
> 
> >> From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
> >> Sorry, no, no change here with that. 
> 
> Eli Zaretskii writes:
> > ??? 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?
> 
> Ah, I'm sorry, I forgot about that one, my bad.  You are right, my first
> test case is indeed fixed by your patch.

I'm relieved.  Thanks.

> Just my actual problem is not, including the last script-based test case
> I made.  (Which I was working on the whole evening yesterday :-()

Is there any way of recreating that problem without having to set up
netcat?  (Why is receiving a page from a server different from
visiting the same page as a disk file?  The way shr works, this should
produce exactly the same results, no?)

> >> 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.
> 
> Fact is that vertical-motion is called in the course of determining the
> break (I think as part of "go to the column where it wants to wrap")

Yes, but vertical-motion is only used here to go to a particular
column on the same line.  It never goes down or up.  How's that
related to wrapping lines?

> and that my actual problems and the script test case seem to be
> solved by setting truncate-lines to nil.

I understand, but that doesn't yet explain what exactly doesn't work
correctly.  I'm pretty sure that the code which is responsible is not
in shr-fill-line, because when that runs, the bidi reordering is
disabled by my patch.

> We have two different bugs here, because my first test case is *not*
> fixed just by setting truncate-lines to nil.

Yes.  The question is where is the other code.  Can you spot that?

Failing that, can you describe what exactly do you see, or maybe step
through the code in Edebug and tell which part(s) misbehave?