Can't reliably clean all buffer with chewing_clean_preedit_buf & chewing_clean_bopomofo_buf #715

wengxt commented 2025年07月26日 00:10:40 +02:00 (Migrated from github.com)

Describe the bug
In fcitx, we have been using following function to reset chewing into an empty state. (Not sure why I'm not using chewing_Reset, maybe because it was not originally available?....I'll update fcitx to use it anyway. )

 chewing_cand_close(ctx);
 chewing_clean_preedit_buf(ctx);
 chewing_clean_bopomofo_buf(ctx);

But now it seems to can't clear when there's both preedit & bopomofo

To Reproduce

Steps to reproduce the behavior:
z p space z, and run the code above.

Expected behavior
nothing left in chewing context.

Platform (please complete the following information):

• OS: Arch
• IME: fcitx5-chewing
• Version 0.9.1

Additional context
Add any other context about the problem here.

**Describe the bug** In fcitx, we have been using following function to reset chewing into an empty state. (Not sure why I'm not using chewing_Reset, maybe because it was not originally available?....I'll update fcitx to use it anyway. ) ``` chewing_cand_close(ctx); chewing_clean_preedit_buf(ctx); chewing_clean_bopomofo_buf(ctx); ``` But now it seems to can't clear when there's both preedit & bopomofo **To Reproduce** Steps to reproduce the behavior: z p space z, and run the code above. **Expected behavior** nothing left in chewing context. **Platform (please complete the following information):** - OS: Arch - IME: fcitx5-chewing - Version 0.9.1 **Additional context** Add any other context about the problem here.

kanru commented 2025年07月26日 00:19:50 +02:00 (Migrated from github.com)

It looks like the problem is in chewing_clean_preedit_buf(ctx);
Now it checks if the context is editing the preedit or the bopomofo.

These APIs are for UI-less scenario so it make sense to restore the original behavior and always clear the preedit.

It looks like the problem is in `chewing_clean_preedit_buf(ctx);` Now it checks if the context is editing the preedit or the bopomofo. These APIs are for UI-less scenario so it make sense to restore the original behavior and always clear the preedit.

kanru commented 2025年07月26日 00:47:35 +02:00 (Migrated from github.com)

Previously the UI-less APIs are not very consistent in checking the state machine..

They check if selection was open but do not check if bopomofo is entering. I'll keep the pre-0.9 behavior and think about how to fix them.

Previously the UI-less APIs are not very consistent in checking the state machine.. They check if selection was open but do not check if bopomofo is entering. I'll keep the pre-0.9 behavior and think about how to fix them.

rocka commented 2026年01月19日 18:55:11 +01:00 (Migrated from github.com)

@wengxt

Not sure why I'm not using chewing_Reset, maybe because it was not originally available?.

This API has been available since at least 2005: github.com/chewing/libchewing@2da97a5898

I think the actual reason not to use chewing_Reset before is, this API is meat to "Reset all settings" in older versions of libchewing

github.com/chewing/libchewing@9be48513bc/include/chewingio.h (L208-L214)

It would reset the layout set in chewing_set_KBType too.

However in newer versions of libchewing, the same API meat to "Reset the context but keep all settings"

github.com/chewing/libchewing@a6a8fa4abd/capi/include/chewing.h (L313-L324)

which caused very strange behavior with fcitx5-chewing 5.1.9+ and libchewing 0.8.5:

• https://github.com/fcitx5-android/fcitx5-android/issues/836

@wengxt > Not sure why I'm not using chewing_Reset, maybe because it was not originally available?. This API has been available since at least 2005: https://github.com/chewing/libchewing/commit/2da97a58984027fd6afa99f7a4193bc483f6b771 I think the actual reason not to use `chewing_Reset` before is, this API is meat to "Reset all settings" in older versions of libchewing https://github.com/chewing/libchewing/blob/9be48513bc46bafa134eef4b2bfde6a533470d33/include/chewingio.h#L208-L214 It would reset the layout set in `chewing_set_KBType` too. However in newer versions of libchewing, the same API meat to "Reset the context but keep all settings" https://github.com/chewing/libchewing/blob/a6a8fa4abd3f215e3ba89a7b61702eaf8ca68f5c/capi/include/chewing.h#L313-L324 which caused very strange behavior with fcitx5-chewing 5.1.9+ and libchewing 0.8.5: - https://github.com/fcitx5-android/fcitx5-android/issues/836

kanru commented 2026年01月20日 00:47:29 +01:00 (Migrated from github.com)

@rocka I think it's a bug in the original C version

github.com/chewing/libchewing@e95e79edad/src/chewingio.c (L328-L329)

All configs except

• bChiSym
• bFullShape

are reset to their default value.

This is first introduced in 930d1f63a2 where we merged change from win32-utf8 branch and the definition of config diverged. The 2 runtime configs are still kept in ChewingData directly and they were reset to default by chewing_Reset, namely bChiSym, bFullShape,

I think unfortunately the kbtype was also part of the config that was reset because it was not part of the ConfigData structure.

@rocka I think it's a bug in the original C version https://github.com/chewing/libchewing/blob/e95e79edade76f55ea940457c873a4aa98bbec9c/src/chewingio.c#L328-L329 All configs except * bChiSym * bFullShape are reset to their default value. This is first introduced in 930d1f63a29820b7e0d65c953518a99e27842163 where we merged change from win32-utf8 branch and the definition of `config` diverged. The 2 runtime configs are still kept in `ChewingData` directly and they were reset to default by `chewing_Reset`, namely `bChiSym`, `bFullShape`, I think unfortunately the `kbtype` was also part of the config that was reset because it was not part of the `ConfigData` structure.