>> 
>>> Although the original code only has one checker (IS_WHITESPACE), it serves a dual purpose: it is used to determine if we can wrap after—whitespace and tab allow wrapping after; it is also used to determine if we can wrap before—they don’t allow wrapping before (otherwise you see whitespace and tabs on the beginning of the next line).
>> 
>> That is true.  I suggested to have a single function so that you could
>> in that single function perform the same test, just using two
>> different categories.  then you could basically keep the rest of the
>> logic intact.  If that is somehow not possible, can you explain why?
> 
> IT_DISPLAYING_WHITESPACE works because it was only check for two types of characters. Now we have four. A Boolean function can’t return more than two possibilities. Two Boolean functions combined can express four possibilities.
> 
> | Type      | wrap_before? | wrap_after? |
> |-----------+--------------+-------------|
> | space/tab | no           | yes         |
> | other     | yes          | no          |
> 
> | Type      | wrap_before? | wrap_after? |
> |-----------+--------------+-------------|
> | space/tab | no           | yes         |
> | CJK       | yes          | yes         |
> | other     | yes          | no          |
> | ??        | no           | no          |

I finally wrapped my head around this, yes I can make it one function which returns a enum. If that’s what you mean. In the meantime I’m still reading the unicode document, the unicode algorithm might require much more machinery. For one, the wrap-ability doesn’t only depend of the immediate characters anymore, e.g., a character before the character before could affect this character’s wrap-ability.

Yuan