GNU bug report logs - #22250
25.0.50; Eww fails to break RTL paragraph

Previous Next

Package: emacs;

Reported by: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>

Date: Sun, 27 Dec 2015 19:13:02 UTC

Severity: normal

Tags: confirmed

Found in version 25.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22250 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: bug#22250: 25.0.50; Eww fails to break RTL paragraph
Date: Mon, 28 Dec 2015 17:40:43 +0100
Eli Zaretskii writes:
> Does the patch below fix the problem?

Sorry, no, no change here with that. 


I looked at the code though and I noticed the call stack

  shr-fill-line
   -> shr-vertical-motion
      -> vertical-motion

which is used to find the line break point.  It seems the idea here is
that Emacs' normal line wrap is used, we just go one line down, and
vertical-motion gets us to the place where Emacs has wrapped.  But
Emacs' line wrap is only active with truncate-lines=nil, and
truncate-lines is set to t in eww-mode.  When I set truncate-lines=nil
in shr-insert-document the bug does actually go away.  I do not know why
truncate-lines was set to t in the first place, though, and where that
may have other consequences.


I'm wondering why this bug depends on RTL layout.  I tried my test case
without dir=rtl and with "abc" as text, but that works fine, so RTL
really is a factor.

But that's not right, is it?  Conceptually, the linebreak opportunities
should be the same regardless of the paragraph direction, RTL or LTR.
For mixed text the visual order of the runs for should be different for
RTL paragraphs, but even than the length of the lines and where they are
broken should not change.  Line breaks should be found according to
logical ordering.  Let's say I have:

   aaa bbb אאא בבב

If I have to break it before the last word, I want to get:

   aaa bbb אאא
   בבב

And indeed, fill-paragraph does the right thing with this example.

If I narrow my Emacs window here, it breaks like this, though:

   aaa bbb בבב
   אאא

So there seems to be an even bigger issue in Emacs generally?  At least
Emacs default wrapping behaviour seems not directly usable as a basis
for filling paragraphs correctly.




This bug report was last modified 9 years and 203 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.