Re: Line wrap reconsidered

[Yuan Fu]

> On May 29, 2020, at 2:56 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Thu, 28 May 2020 15:34:28 -0400
>> Cc: larsi@gnus.org,
>> emacs-devel@gnu.org
>> 
>> In the current code IT_DISPLAYING_WHITESPACE can check for can_wrap_before 
>> and can_wrap_after in the same time, but in my new code, we have to perform 
>> two checks in the same iteration, because some char can wrap before but now 
>> after, and some can wrap after but not before, etc. 
> 
> Then you'll need to augment the test
> 
>  else if (may_wrap)
> 
> with a test that the current character can be at BOL.  Maybe you
> should also make may_wrap a tristate instead of just a boolean YES/NO.
> 

I think I did jus that, i.e., if (may_wrap && char_can_wrap_before(it)).

>>> Which "continue" are you alluding to here?  Do you mean "lines are
>>> continued"?  because if lines are not being wrapped, we have only one
>>> choice: go back to the last wrap point we found, end the screen line
>>> (a.k.a. "break the line") there, and continue with the text on the
>>> next screen line.
>> 
>> I think there is another option where we wrap at current point. On line 
>> 23356:
>> 
>>                            /* If line-wrap is on, check if a
>>                               previous wrap point was found.  */
>>                            else if (wrap_row_used > 0
>>                                     /* Even if there is a previous wrap
>>                                        point, continue the line here as
>>                                        usual, if (i) the previous character
>>                                        was a space or tab AND (ii) the
>>                                        current character is not.  */
>>                                     && (!may_wrap
>>                                         || IT_DISPLAYING_WHITESPACE (it)))
>>                              goto back_to_wrap;
>> 
>> I was alluding to this “continue”: “continue the line here as usual”. What 
>> does it mean? Does it mean we insert a line break here? I think your 
>> response below confirms my guess.
> 
> Yes, "continue the line" here means we break the line here instead of
> going back to the wrap point.  This code handles the case when there's
> a previous wrap point, but the current character fits exactly on the
> line, and that current character is a TAB or SPC.
> 
>>> I mean the indentation: the original code used TABs and spaces, but
>>> your code uses only spaces.
>> 
>> How do I fix it? Any guideline file?
> 
> Just make sure indent-tabs-mode is non-nil when you edit C files.

Ok.

> 
>>>> and the redisplay iterator will still go through them LTR
>>> 
>>> Not sure what you mean by "go through them LTR".  The iterator can
>>> move forward or backward, or even jump to a far-away place.  You
>>> cannot assume that the next character examined will be the next
>>> character in the buffer.
>> 
>> Essentially I want to ask “if may_wrap == true, what does that mean? (In 
>> bidi context)” Did the character to the left of me (on glass) set it or the 
>> character to the right of me set it?
> 
> The one to the left.  But it is not necessarily the "previous"
> character in buffer position order.

I see, but then I don’t don’t understand how does the current code work with 
bidi display. In bidi context, space char can’t appear on the right of the 
line, which is the beginning of a logic line, right? That requires the logic to 
reverse. Is there something I’m missing?

What I’m saying is:

Normal text: space: can wrap: after (in logical order), right (in visual order)
Cannot wrap: before (in logical order), left (in visual order)

Bidi text: space: can wrap: after (in logical order), _left_ (in visual order)
Cannot wrap: before (in logical order), _right_ (in visual order)

Since may_wrap’s meaning is in terms of left and right, it need to be reversed 
in bidi text, no?

> 
>> Actually, I just tried again and the code works for bidi. Maybe last time I 
>> didn’t turned on word-wrap while thinking I did.
> 
> You need to try both with bidi-paragraph-direction set to
> left-to-right and right-to-left.  If both work, then the code is OK.


One more question. If I type 123456789... and set bidi-paragraph-direction to 
‘right-to-left, it is still 123456789…, just aligned to the right. I expected 
to see …987654321, that’s what right-to-left mean in Chinese text. Why the 
order of each character not revered? UAX#9 didn’t say anything helpful.

Yuan