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

Previous Next

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 19:15:50 +0100

>> Eli Zaretskii writes:
>> > Does the patch below fix the problem?

>> From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
>> Sorry, no, no change here with that. 

Eli Zaretskii writes:
> ??? It certainly solved the problem with your original HTML file
> visited with eww-open-file.  Doesn't it solve that for you?  Are you
> sure you tested correctly?  And what exactly did you test?

Ah, I'm sorry, I forgot about that one, my bad.  You are right, my first
test case is indeed fixed by your patch.

Just my actual problem is not, including the last script-based test case
I made.  (Which I was working on the whole evening yesterday :-()

>> 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.
>
> No, that's not how this works, AFAIK.  (But Lars can correct me if I'm
> wrong.)  What it does is go to the column where it wants to wrap and
> then checks if it's at EOL.  If not, it goes back and looks for a
> place to insert a newline.  Rinse, repeat.

Fact is that vertical-motion is called in the course of determining the
break (I think as part of "go to the column where it wants to wrap") and
that my actual problems and the script test case seem to be solved by
setting truncate-lines to nil.

We have two different bugs here, because my first test case is *not*
fixed just by setting truncate-lines to nil.

>> I'm wondering why this bug depends on RTL layout.

Here I was talking about the script test case I sent, not the first test
case, which I had entirely forgotten about.

> I'm wondering why it happens at all, after the patch I sent.  When
> bidi-display-reordering is set to nil, there is no RTL layout, any
> text is laid out in strict logical left-to-right order.
>
>> I tried my test case without dir=rtl and with "abc" as text, but
>> that works fine, so RTL really is a factor.
>
> It cannot be, not when bidi-display-reordering is bound to nil.
> Something else is at work there.

Again, I am sorry for the confusion.

Previous Next

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