Return behavior is changed comparing to 0.5.1 #714

Describe the bug
When zuin is not completed, return does not commit existing string, instead,
chewing_keystroke_CheckIgnore -> false
chewing_keystroke_CheckAbsorb -> false
chewing_commit_Check -> false

To Reproduce
Key sequence: "z" "p" "space" "z" "p" "Return".

Expected behavior
I can see rust return the result as "bell", I'd assume it indicates that it's an error, which means this key should be absorb. I briefly check the capi, there's no way to check Bell.

Screenshots
Platform (please complete the following information):

• OS: Arch
• Desktop: N/A
• IME: fcitx5-chewing
• Version 0.9.1

In 0.5.1, the keystrokeRtn can be sth like KEYSTROKE_ABSORB | KEYSTROKE_BELL

However, now it's a variant can't be both absorb and bell.

Thanks for the report!

I was pretty sure that we are returning KEYSTROKE_BELL in the API but it turns out it was only available via direct struct inspection. In our test we have

github.com/chewing/libchewing@2d4b995ba8/tests/testhelper.c (L379-L380)

So the backwards compatible behavior should be returning chewing_keystroke_CheckAbsorb=true in this case.

I can also add a new method to check Bell condition.

The actual behavior is still different:

Check the video below:

https://github.com/user-attachments/assets/01786c4e-7c74-4cfd-85bf-a040ce1bfc54

with 0.5.1, the "分" is committed as returned with chewing_commit_Check, zuin is kept.
with 0.9.1, chewing_commit_Check doesn't return true.

I see. So you mean there are two bugs here

1. We don't return chewing_keystroke_CheckAbsorb=true when last key was an error
2. Previously we commit the pre-edit buffer even if composition is ongoing

I think the current behavior for composition handling is more intuitive and the 0.5.1 behavior is more like a bug.