GNU bug report logs -
#22250
25.0.50; Eww fails to break RTL paragraph
Previous Next
Full log
View this message in rfc822 format
>> 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.
This bug report was last modified 9 years and 221 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.