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

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

Benjamin Riefenstahl writes:
>> I have uploaded this now to my private webserver as
>> <https://odoacer.turtle-trading.net/abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-abc-test.html>.
>> This URL reproduces the problem for me after "G RET".
>
Eli Zaretskii writes:
> Not for me, it doesn't.  I tried "G RET" quite a few times, it always
> displays correctly.

You're right it works now, since

  03dbfb9 * (eww-setup-buffer): Restore left-to-right defaults

Yesterday I had still been on the earlier f9d87dd.  Oh the joy of moving
targets ;-)

But that's ok, so this case and my script text case are solved in
practice.  I'm still concerned about the behaviour of vertical-motion in
this, though.

On practical level, there is still the matter of paragraphs using
diacritics.  Do you have an idea how to fix those?


For your other questions:

>> In the bad case, for the first line, everything looks the same,
>> vertical-motion gets called with the same parameter, but when it returns
>> point is at 161.  Which is not good.
>
> What does window-hscroll return in each of these two cases?

I checked that again with the commit before 03dbfb9.  I inserted a call
to `message' to make sure I got the right window.  It's 0 for the good
case, 67 for the bad case.  Basically the same as it->w->hscroll on the
C level.

>> In the good case, it->w->hscroll is 0, in the bad case it->w->hscroll is
>> 68.

>> Experimentation tells me that the interpretation of window-hscroll
>> (whether it refers to the left or the right margin) depends on
>> bidi-paragraph-direction, is that right?
>
> Yes and no.  It depends on what you mean by "interpretation".

I was starting from the doc on window.hscroll in window.h and the
docstring for window-hscroll.  The docstring says

  Return the number of columns by which WINDOW is scrolled from left
  margin.

But with bidi-paragraph-direction set to RTL window-hscroll works with
respect to the right margin.  I just verified again.

>> Note that at the point when vertical-motion is called and gives
>> different answers, bidi-paragraph-direction is always right-to-left, so
>> it looks like some window parameter that depends on
>> bidi-paragraph-direction is cached somewhere?
>
> The value of bidi-paragraph-direction shouldn't matter when
> bidi-display-reordering is nil (I've just went through the entire code
> and didn't see any place where we use that value when
> bidi-display-reordering is nil).  But just in case I missed something,
> try bindings bidi-paragraph-direction to nil or left-to-right where I
> bind bidi-display-reordering, and see if that helps.

With both variables set in shr-insert-document, I consistently get a
seemingly correctly wrapped but left justified (LTR) paragraph,
regardless which version I use, I tried in 5049827 (the one before
03dbfb9) and with the current 88e2de2.  This is with the above mentioned
URL.

> P.S. I'm going to commit my patch, as it definitely improves things
> and is clearly TRT to do (and I'm tired of stashing it ;-).

Got it.