The execution order of delete_surrounding_text() and commit_text() gets jumbled

[ShikiOkasaka]

Which distribution and version?:
Ubuntu 23.10 and Fedora 39 Beta

Which desktop environment and version?:
GNOME 45.0

Which session type?:
Wayland with GTK_IM_MODULE=ibus
X11

Note: Without GTK_IM_MODULE=ibus, IBus.Engine.get_surrounding_text() returns text positions in octets not in the number of characters on Wayland.

Which application and version?:
gnome-text-editor 45.0
gtk4-demo-application 4.12.3

IBus version?:
IBus 1.5.29-rc1 using IBus Python API for IBus.Engine

Issue description:
The execution order of delete_surrounding_text() and commit_text() appears to be jumbled in gnome-text-editor and gtk4-demo-application.

Steps to reproduce:

1. Enter text "123" in the text editor.
2. Execute delete_surrounding_text(-1, 1) and then commit_text(IBus.Text.new_from_string('ABC'))
3. The remaining text should be "12ABC" but you'll get "123AB".

With gedit, you can get "12ABC" as expected.

This steps can be tested by adding the code like below to engine.py:

        if keyval == keysyms.Return:
            self.delete_surrounding_text(-1, 1)
            self.commit_text(IBus.Text.new_from_string('ABC'))
            return True

On Wayland, this steps work as expected if GTK_IM_MODULE=ibus is not defined.

Can you reproduce your problem when you restart ibus-daemon? (yes / no):
yes

Do you see any errors when you run ibus-daemon with the verbose option?:
no

Can you reproduce your problem with a new user account instead of the current your account? (yes / no):
yes

[fujiwarat]

I made the patch.
I hope Fedora 39 will be released next week.

[fujiwarat]

Although your patch does reduce the occurrence of the bug, libhangul/ibus-hangul#118 still occurs sometimes. Is this bug different so that I need to open a separate thread?

Don't comment about ibus 1.5.28 and also your issue isn't relative with surrounding text.

[fujiwarat]

I decided to commit this fix to 1.5.29-rc2.