Preview available at https://egui-pr-preview.github.io/pr/8068-text-agent-textarea
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

View snapshot changes at kitdiff

Nice work.

I also considered synchronizing the entire text between egui and TextEdit. However, since the original approach is $O(1)$ while full synchronization is $O(\text{text size})$, I was concerned about potential performance degradation and decided not to go for it.
In practice, though, given that egui is an immediate-mode UI, the impact is likely negligible. Since I haven't benchmarked it, my thought may well be a case of premature optimization. (My approach (#8045) is also $O(N)$, but $N$ is limited to a small chunk of text being written, which should remain modest in typical usage.)

One clear advantage of this PR over both the original approach and my own (#8045) is that it enables auto-completion to continue working when the cursor is moved. While this can be partially worked around on top of my approach (e.g., by prepending text after resetting the text agent), this PR provides a more robust solution.

@umajho That's a good point. I like your idea, but it wasn't working for me on the latest commit (keyboard is still resetting?). I opted for the simplest approach, but maybe partial text replacement is superior if you can manage the unicode difficulties.

@emilk Thanks for looking at it - I rebased on main to resolve the conflict

@umajho @cjgriscom

Regarding #8068, when typing the Korean word "않았다" on Android (using the Cheonjiin keyboard), a part of the first character is duplicated, resulting in "안않았다."

I’ve confirmed that this issue is resolved in #8045. It seems that some additional work might be needed to apply this fix to #8068 as well.

@umajho @rustbasic Is it just a matter of applying this: f139c60 ?

@umajho … but it wasn't working for me on the latest commit (keyboard is still resetting?). …

…

That's odd. #8045 appears to fix the keyboard reset issue based on my testing:

Prior to #8045	With #8045

@umajho @cjgriscom

Yes, it appears that the keyboard reset issue has also been resolved in #8045.

… Is it just a matter of applying this: f139c60 ?

The fix in #8045 was under the assumption that only a small portion of the text exists in the text agent. Specifically, the text originally retained in the text agent is compared with the text updated in the text agent during IME composition, and based on that comparison, it determines what action to take.

The code changes to on_composition_end in f139c60 are only part of the fix: changes in places like on_input are also part of it.

To be honest, since the assumption has now changed to the text agent containing the entire synchronized text, I'm not really sure how to migrate the fixes implemented in my PR anymore…

@umajho You're right, it seems to work on the demo now. I must have done something wrong

IME is bigger in scope than what I'd like to address here, so I'd rather defer to your PR in that case. I left a note there about one remaining issue.