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: Wed, 30 Dec 2015 21:22:06 +0100
> 
> > I'll need a clear test case to look into this.
> 
> Try the attached patch.  It reverts parts of Lars' fix and adds a debug
> message to shr-vertical-motion.
> 
> For a base-line test, execute
> 
>   ./emacs -Q -nw --eval '(eww "https://odoacer.turtle-trading.net/abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-test.html")'
> 
> Once the page is loaded, press "G RET".  This second load reproduces the
> problem for me.  I get this protocol in the message buffer:
> 
>   Contacting host: odoacer.turtle-trading.net:443
>   bpd: right-to-left pt: 1 hscroll: 0
>   bpd: right-to-left pt: 97 hscroll: 0
>   bpd: right-to-left pt: 193 hscroll: 0
>   bpd: right-to-left pt: 289 hscroll: 0
>   Contacting host: odoacer.turtle-trading.net:443
>   bpd: right-to-left pt: 1 hscroll: 57
>   bpd: right-to-left pt: 153 hscroll: 57
>   bpd: right-to-left pt: 305 hscroll: 57
> 
> The first run is as I expected.  The second run has point at 1 and
> hscroll at 57 (this is in a terminal, that's why the actual number is
> different from before).  According to my logic that should not be
> possible.  When the point is at 1, then hscroll should be 0 otherwise
> point would not be visible.  Unless some intermediate state is
> permissible.  But than shr could not rely on hscroll and therefore not
> on vertical-motion.
> 
> Now as a second experiment, remove the ";" from bidi-paragraph-direction
> in shr-insert-document.  Repeat the test.  Now the result should look
> correct.  Somehow bidi-paragraph-direction does make a difference.

No, it's not bidi-paragraph-direction, at least not directly.  The
problem is that shr-fill-lines needs to start in a window that is not
scrolled horizontally, because otherwise vertical-motion will move to
a wrong place (it interprets the column in its argument to be relative
to its left edge).  When EWW doesn't clear the previous value of
bidi-paragraph-direction, the message "Loading URL ..." that is
displayed when you type "G RET" is inserted into a buffer with a
right-to-left paragraph direction, and bidi-display-reordering was not
yet set to nil, so inserting that message with such a long URL causes
the window to auto-hscroll.  So when shr-insert-document is called,
and resets bidi-display-reordering, the window is already hscrolled,
and filling lines misbehaves.

I fixed that now by forcing zero hscroll on the window before the
line-filling starts.

I guess we can now close this bug?

Thanks.