You can use "Candidate" (at least in the method/function names, less critical for local variables), for readability.
(Unless this means candy/sweets :)

Candi's sweet, I think I'm keeping it ;) Also it shows a lot in this file, trying to save some space:)

Not sure why you had to / need to add this condition - as it feels it should always exists ?
Is this a requirement for how this new keyboard works - or just a bug and something we forgot that you logically fixed.
Please add a comment if the former (saying it's for the zh keyboard).

I have it that when tapping on the input text box, I need to remove the candidates if they exist. Then when I'm modifying the text, the dimen here somehow becomes nil then crash. I remember in Ja keyboard it happened too, but I couldn't make it happen again. With the Chinese keyboard, with candidates shown, it always appears.

See ! How readable your above comment is. Imagine I had to read:

I need to remove the candi if they exist. [...] With the Chinese keyboard, with candi shown, it always appears.

Your code should read as easy as your posts :)
(Why had you removed the sweets ?! :)

I'm not familiar with the widget in question, so this is more of a generic comment about this specific pitfall:

dimen fields are often set at draw time (e.g., in paintTo), so for widgets that get destroyed, this may not always be set when you expect it to.

Depending on what makes the most sense, you can either side-step the issue like you did, fix the widget so that stuff doesn't get randomly destroyed if it doesn't make much sense, or forcibly compute dimen before paint via the getSize method ;).

One practical consequence of this is the difference between the two signatures for setDirty: when you pass a lambda, it's often because you want to use a dimen field for the refresh region, but it might not be set yet at call time. But since UIManager consumes the lambda post-paintTo, it magically works ;o).

I tried

if not inputbox._frame_textwidget.dimen then
    inputbox._frame_textwidget.dimen = inputbox._frame_textwidget:getSize()
end

after calling inputbox:delChar then inputbox:addChars, it's no longer crashing :) But somehow I still can't immediately have the cursor where I clicked. It may be because the new text is not drawn yet?
Also I'm here modifying the supposedly private property of inputbox thanks to Lua letting me do it. So I think I'll stick with the side-step, as my case is quite rare.

Yeah, depending on what exactly you call getSize() on, it may not always behave as expected (e.g., a container with multiple child widgets, some of 'em being undrawn/destroyed or whatever), so, it can indeed be a bit iffy ;).

(I think there's still an insane bit of hackery for a similar shenanigan in ReaderFooter that still gives me nightmares ;p).

A bit confused what this does. A verbal method name could have make it clearer. emitUtf8ModeKey ?
Anyway, a small comment feels needed :)

I was trying to clean the stage (remove candidates) when tapping on the Earth button. A verbal one is indeed better.

So, may be it should be named as what it does ? :cleanStage() (or more explicite, I dunno what "stage" means :).
And may be in the zh virtualkeyboard, the utf8key should call cleanStage() ?

Or does calling emitUtf8Key() really means something for other keyboards ?

In zh virtualkeyboard, the util.wrapMethod setup is uft8key calls wrappedSeparate (which does the same thing as typing Separation thus cleanStage) before calling the actual emitUtf8ModeKey.

With show candidates on, you type stroke 一 and get character 一 in the unfinished state (so you can add strokes to it or finish it to start a new character.) Then type 丨 and get 十[丁丅] which says the current on-stage character is 十 but there are two other candidates "off-stage". The extra [丁丅] is not part of the actual text so will need to be cleaned when a finishing key or other none-stroke key is hit, which includes the uft8 key. Otherwise the off-stage characters are left on-stage to mess with user operations.

By the way, the in-place candidates is my design :) In other similar cases, there would be a section on top of the keys dedicated to showing candidates so there's no need to clean the actual text.

By the way, the in-place candidates is my design :)

I find it quite nice: you don't have to move your eyes away from the line you are typing.

I dunno how this feels to native Chinese writers, but when testing, and in 十[丁丅], it was a bit hard for me to distinguish the brackets from these Chinese quite straight glyphs. (Dunno if other unicode chars with more spacing or more or less thickness could help.)

I tried different brackets, the current [] looks best. It's easy to distinguish because they are out of the grid :)

This name "emitUtf8ModeKey()" does not "sound" right - my bad suggestion :)
Here, we're defining the callbacks that happens when tap/hold/swipe on this globe key: so, we're not asking self.keyboard to "emit the utf8 key". At best, we would notify it that "utf8 key emitted or handled or about to be handled".
But still, this sounds strange: why do we need to do that ? Why for this globe key, and why not the others ?! Because your zh keyboard happen to still have this function key (but not "shift" nor "alternate").

So, if we don't want to explain that, may be name it onSwitchingKeyboardLayout or something like that, with a comment saying that some "state" keyboards (ie. zh) may want to be notified of that.

Agree. Have changed it to this name.

I tried to use it to actually type on my android phone and it turned out the Separation key is hit way more often than the Switch key. So I made some changes to the layout hoping to reduce finger movement. I also changed wording of the Switch key 换字 to 下一字 because it turned out 换 has its traditional form 換. The new wording 下一字 meaning "next character" is also more natural despite being more verbose.