[PATCH RFC] Add language and text-direction to text protocol

[Bill Spitzak]

On 01/31/2013 10:42 AM, Michael Hasselmann wrote:

> You need to place your cursor at the left or right end of a text entry
> (actually, right or left of the possibly already existing text, on
> focus-in). An explicit text direction event makes it easier than having
> to wait and parse for the input method's text

It sounds like this "language direction" is for placing the cursor in 
the preedit/commit string? I'm a bit confused as to what you are talking 
about.

I think the commit/preedit string should contain an actual cursor 
position, it can be between any two bytes in it. There is no reason to 
limit it to the start/end.

> (which you can only really
> do after receiving the commit string, not while showing the preedit
> string). Without the extra event you have to accept annoying UI
> adjustments while already typing in text.

I sure hope the client can do *exactly* the same thing with the preedit 
versus the commit string. There is no reason for the data to be 
different. The only difference is that the client remembers what text 
was placed by the preedit string so it can delete it on the next preedit 
or commit or if the input method aborts.

>> This might require the client to send the input method a large block of
>> "context", such as the entire current paragraph, so that it can figure
>> out the best insertion text so the direction indicators are right.
>
> We already do send surrounding text, no?

Yes I guessed that was happening. I thought this would contain enough 
information in Unicode for the input method to determine the direction.

My concern is that a stupid client, and input methods who have to insert 
them to make sure, would result in large numbers of direction indicator 
characters being inserted into the text. If the input method as part of 
the preedit/commit strings is allowed to delete some of the bytes of the 
surrounding text, it could then remove redundant direction indicators.

As I see it interaction would be something like this:

1. Client sends the entire surrounding text to the input method as a 
single block of UTF-8 bytes, plus two byte offsets into it indicating 
the selected region. This text should be the same unit that is sent to 
Pango, a paragraph (the input method can handle less being sent but 
might not be as smart). If the selected region contains a paragraph 
break, or is very large, the client elides a large chunk in the middle 
so it is one paragraph.

2. As user types, input method sends either preedit or commit events. 
These contain:
  1. two offsets for how to move the two ends of the selected region to 
get the block of bytes to replace (ie it can decide to delete some of 
the surrounding text, and also to not delete all of the selected region).
  2. A block of bytes of replacement text
  3. Two offsets into that to indicate a new selected region and cursor 
position.

The only difference between preedit and commit is that the client 
remembers the state before the preedit and restores it before applying 
the next preedit or commit. It might also show the selected region and 
cursor differently.