bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Benjamin Riefenstahl
Subject: bug#22250: 25.0.50; Eww fails to break RTL paragraph
Date: Tue, 29 Dec 2015 23:33:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

>> Benjamin Riefenstahl writes:
>> On practical level, there is still the matter of paragraphs using
>> diacritics.

Eli Zaretskii writes:
> Is that the only remaining problem?

At this point every problem in my application and test cases that I
still see involves diacritics.  And thank you (and Lars) for your
patience with that.

> Or does this mean my suggestion didn't work, and is not required,

It does fix the issue with my first test case, with the Latin text in an
RTL document.  I just checked and that one does not work if I revert
your change on HEAD.  Your change did not fix the issue with Hebrew text
without diacritics, that got fixed with Lars' commit 03dbfb9.

>> I'm still concerned about the behaviour of vertical-motion in this,
>> though.

> Reading the rest of your message, I'm not sure.

I am weary that there still are dragons with vertical-motion and/or
hscroll.  I don't like it that two situations behave differently,
although they have the same values in variables and the same window
configuration, point at in same place, and - from what I can see -
horizontal scrolling also at the same level (given that point is at bol,
hscroll *should* be 0, otherwise point would not be visible, right?).
Still window-hscroll gives a bogus value in the bad case.

>> 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.

> Does this mean there's one more problem?

Not with my application and test cases.  But it seems to me, that
contrary to what you believed, bidi-paragraph-direction=nil still does
have an effect on the layout, even when bidi-display-reordering is nil.
It fixes the paragraph wrapping for Hebrew text without diacritics in
the version before Lars commit, while bidi-display-reordering alone does
not.  It also makes the paragraph LTR, but that does not surprise me as
much.

An insight that I just had - you maybe are aware of it already - is that
shr-tag-html, the function that sets bidi-paragraph-direction from the
<html> element, is called from with-in the body of shr-insert-document
(as a subroutine of the recursive shr-descend, basically).  That
explains why Lars' patch (resetting bidi-paragraph-direction at the eww
level each time before calling into shr) and setting
bidi-paragraph-direction in shr-insert-document have the same effect on
the wrapping.  It also explains why we get an LTR paragraph, when we
shadow the buffer-local variable in this way.  And it explains why I got
the problem only on "G RET".  The problem was triggered between the
start of the body of shr-insert-document and the call to shr-tag-html
when bidi-paragraph-direction is right-to-left between those two places.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]