The interaction between composition and `updateText`/`updateSelection` should be more clearly defined

At the moment, in Chromium's implementation of EditContext, if you push a text/selection update into the edit context while a composition is in progress, further composition updates will continue to happen at the old selection position. See also this issue.

In a situation (which I think is typical of an EditContext-based editor) where the editor library will push changes made to its document via sources other than the edit context into the edit context in order to keep that synced with its own document model, this is going to cause issues.

I would expect updates to the edit context's text/selection model that don't directly impact the text around the composition to move the context's understanding of where the composition happens. Updates that do touch the composed text should probably abort the composition.

The current interface, where updateText and updateSelection are two separate methods, even though the data they interact with is deeply entangled, makes addressing this somewhat awkward, because a state update isn't a single atomic thing, but two imperative calls, with the context being in a bogus state in between them.

I was actually surprised to see that (at least in Chrome's implementation), updateText does not affect selectionStart/selectionEnd—i.e. when the selection is at position 10 and you call updateText(0, 6, ""), it stays at 10 (or is clipped to the end of the document) rather than moving to position 4 along with the text that it points at. Is that an intentional decision, or something that just fell out of the most straightforward implementation? If updateText did adjust the selection (which seems like it will be a welcome behavior in almost every situation), it provides more of an atomic way to push updates into the context, and may make it easier to define composition behavior in response to such an update.

Given all that, my proposal would be:

• Make updateText affect the selection start and end, moving them by text.length - (rangeEnd - rangeStart) when pos >= rangeEnd, or to rangeStart + text.length when pos > rangeStart && pos < rangeEnd.
• When a composition is active while updateText is called
  • If the updated range does not overlap with the composed range, move the composition position in the same way
  • If it does overlap, abort the composition
• When a composition is active while updateSelection is called with a selection that differs from the current selection, the composition should probably be aborted

Start by reviewing the EditContext API behavior described here and the linked Chromium issue 379170477. Clarify the intended interaction between updateText, updateSelection, and active composition, including selection movement, composition relocation, and abort conditions; done means the interface semantics are explicitly resolved.