From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 22250@debbugs.gnu.org, larsi@gnus.org
Subject: bug#22250: 25.0.50; Eww fails to break RTL paragraph
Date: Tue, 29 Dec 2015 23:33:33 +0100 [thread overview]
Message-ID: <87y4cc996q.fsf@justinian.turtle-trading.net> (raw)
In-Reply-To: <83poxpc6hz.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 29 Dec 2015 23:03:20 +0200")
>> 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.
next prev parent reply other threads:[~2015-12-29 22:33 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-27 19:11 bug#22250: 25.0.50; Eww fails to break RTL paragraph Benjamin Riefenstahl
2015-12-27 19:27 ` Eli Zaretskii
2015-12-27 23:09 ` Benjamin Riefenstahl
2015-12-28 3:32 ` Eli Zaretskii
2015-12-28 16:40 ` Benjamin Riefenstahl
2015-12-28 17:12 ` Eli Zaretskii
2015-12-28 17:49 ` Eli Zaretskii
2015-12-28 18:15 ` Benjamin Riefenstahl
2015-12-28 18:30 ` Eli Zaretskii
2015-12-28 21:23 ` Benjamin Riefenstahl
2015-12-29 16:47 ` Eli Zaretskii
2015-12-29 20:55 ` Benjamin Riefenstahl
2015-12-29 21:03 ` Eli Zaretskii
2015-12-29 22:33 ` Benjamin Riefenstahl [this message]
2015-12-30 17:04 ` Eli Zaretskii
2015-12-30 20:22 ` Benjamin Riefenstahl
2015-12-30 20:30 ` Benjamin Riefenstahl
2015-12-31 15:26 ` Eli Zaretskii
2015-12-31 18:10 ` Benjamin Riefenstahl
2015-12-31 18:23 ` Eli Zaretskii
2015-12-30 17:15 ` Eli Zaretskii
2015-12-28 16:46 ` Lars Ingebrigtsen
2015-12-28 19:07 ` Benjamin Riefenstahl
2015-12-28 19:29 ` Eli Zaretskii
2015-12-27 19:30 ` Lars Ingebrigtsen
2015-12-27 19:38 ` Eli Zaretskii
2015-12-27 19:45 ` Eli Zaretskii
2015-12-27 19:49 ` Lars Ingebrigtsen
2015-12-27 20:22 ` Eli Zaretskii
2015-12-27 20:28 ` Eli Zaretskii
2015-12-27 21:00 ` Eli Zaretskii
2015-12-27 21:10 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y4cc996q.fsf@justinian.turtle-trading.net \
--to=b.riefenstahl@turtle-trading.net \
--cc=22250@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).