Re: Line wrap reconsidered

[Yuan Fu <casouri@gmail.com>]

> 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