[BUG] auto/ghost navigation issue or move function issue with m17n layouts

[rank-coder]

Describe the bug Ghost navigation in some cases when commited. If an m17n layout uses the move function at pressing space, typing-booster handles it incorrectly. Sometimes the insertion pointer navigates leftwards endlessly and sometimes the ins pointer navigates one or two positions back. For example: there is a Bengali keyboard layout in which if you type a consonant letter and after that another consonant letter, m17n will insert a linker in between those two letters. Suppose, the first consonant is mapped with "k" and another with "s" and some others with "sh", "sf" etc. If I write "ks" the m17n layout will see that I have typed "k" and started typing another consonant which can be either "s", "sh", or "sh". If I press space after "ks" then m17n will know that the two consonants are "k" and "s" and move the ins pointer in between k and s, insert a linker then move back to the end. When m17n does that, ityping-booster somehow starts moving the insertion pointer backwards endlessly. Sometimes without moving backwords endlessly, it just moves to the front of preedit buffer of m17n.

To Reproduce Steps to reproduce the behavior:

1. Use an m17n layout with typing-booster which uses the move function. For example I'm using this one: https://github.com/rank-coder/khipro-m17n
2. Type two consonants (where the second one is ambiguous untill committed) on after another and press space.
3. This one recorded under wayland

https://github.com/mike-fabian/ibus-typing-booster/assets/54497225/2dd4840a-c1f0-47ed-81c8-c4ef0467b6c6

or sometimes navigates to the front of preedit buffer: (this one recorded under xorg)

https://github.com/mike-fabian/ibus-typing-booster/assets/54497225/825b6442-5afb-400a-acb8-d55b993d3bd5

4. See error

Expected behavior Typing booster should be able to handle those move functions properly that are executed on commit without triggering an infinite scroll.

Screenshots or videos

ibus-typing-booster version? 2.25.9

ibus version? IBus 1.5.30

Distribution and version? Fedora Linux 40 Workstation

Desktop and version? Gnome

Xorg or Wayland? Wayland has this issue in all apps xorg has this issue only in certain apps (e.g. Telegram Desktop)

Additional context

[rank-coder]

I edited the issue since I discovered the following: Wayland has this issue in all apps xorg has this issue only in certain apps (e.g. Telegram Desktop)

[mike-fabian]

I cannot yet reproduce that. Can you help me a bit more to reproduce it?

What is the exact sequence you are typing? I tried ks but that produces ক্স (U+0995 BENGALI LETTER KA U+09CD BENGALI SIGN VIRAMA U+09B8 BENGALI LETTER SA U+0020 SPACE) which is the expected result, right?

I typed into gedit on Fedora 40 on Gnome Wayland.

Looking at your first video, you also seem to type ks (is that right?). I cannot see whether the space appears or not before the cursor starts to rush left.

[mike-fabian]

I also tried the Telegram Desktop app on Fedora 40 using Xorg and could not reproduce the problem either.

[mike-fabian]

Here is a video where I tried typing ks many times into gedit on a Gnome Wayland desktop on Fedora 40. ibus-1.5.30-5.fc40.x86_64 ibus-typing-booster-2.25.11-1.fc40.noarch gnome-shell-46.3.1-1.fc40.x86_64 gedit-46.2-1.fc40.x86_64

https://github.com/mike-fabian/ibus-typing-booster/assets/2330175/176bad70-fc0a-4821-b475-c431c6b064b1

[mike-fabian]

Thank you to @rank-coder for the old version of khipro-m17n which made it possible for me to reproduce the problem typing ks.

[rank-coder]

And I'm sorry for not noticing your messages here before. I was a bit busy then. And since you didn't ping me here, I didn't get a notification.

[mike-fabian]

@rank-coder I think I have a fix, I doing some more testing...

[mike-fabian]

Old version of bn-khipro, added here for reference because it makes it easy to reproduce the bug:

bn-khipro(old).mim.gz

Using that version provided by @rank-coder I can easily reproduce the problem by typing ks.

[mike-fabian]

Reproducing on wayland by typing ks:

https://github.com/mike-fabian/ibus-typing-booster/assets/2330175/9d8aa4a5-1be0-4d3f-8e6e-0c746fa4c523

[mike-fabian]

Reproducing on Gnome Xorg:

https://github.com/mike-fabian/ibus-typing-booster/assets/2330175/1d9e2fcf-87e4-4e97-a663-344ec28608ce

[mike-fabian]

@rank-coder The problem is also reproducible on Xorg. In the above video for Xorg, gedit already contains a and the cursor is to the left of the a. Then I type ks. After that, I should have ক্স |a where | indicates the cursor position. But I get ক্স| a, i.e. the cursor has been moved one position to the left from the correct position. This happened because of incorrectly forwarding a Left key event after the commit. In case of wayland there seems to be something broken with forward_key_event() at the moment. Because even though only a single Left key event is forwarded, this repeats endlessly until the cursor is at the beginning and cannot go further left.

[mike-fabian]

The reason why the incorrect Left is forwarded is:

• After typing ks, the transliteration in the preedit contains U+0995 BENGALI LETTER KA U+09B8 BENGALI LETTER SA, i.e. the length of the preedit is 2.
• When a space is typed now, the string to be committed is transliterated again as if a space followed. Because adding a space might change the transliteration. In this case the transliteration becomes U+0995 BENGALI LETTER KA U+09CD BENGALI SIGN VIRAMA U+09B8 BENGALI LETTER SA. Now the length of the string to be committed is 3, not 2.
• Shortly before the commit, the cursor position in the preedit is calculated, see the function get_caret() in hunspell_table.py. But get_caret() didn’t know that a space had been added and therefore gets the cursor position in the preedit wrong, it returns 2, the correct value is 3.

I have fixed this now by adding an optional parameter to get_caret() which indicates another msymbol which should be added behind the current cursor position. This might changed the length of the transliteration before that cursor position and now this length can be calculated correctly.

[mike-fabian]

@rank-coder I pushed a commit which I believe fixes this to the release-candidate-2.25.12 branch.

[mike-fabian]

Testing ibus-typing-booster-2.25.12 with the fix on Gnome Wayland:

https://github.com/mike-fabian/ibus-typing-booster/assets/2330175/45522d61-72ea-4344-9cb3-92e306b85905

[mike-fabian]

@rank-coder Fix included in the 2.25.12 release: https://github.com/mike-fabian/ibus-typing-booster/releases/tag/2.25.12

[mike-fabian]

@rank-coder The problem you reported happened when the cursor is at the end of the preedit and you type a space. I think that problem is fixed in https://github.com/mike-fabian/ibus-typing-booster/releases/tag/2.25.12

There might still be problems when a space or a Return is pressed while the cursor is somewhere in the middle of the preedit.

For example, with the m17n input method t-latn-post one might type gru"n| and then the preedit shows grün| where | indicates the cursor position. When one now types Left 2 times the cursor is here in the input gru|"n and in the preedit grü|n (in the preedit the cursor cannot be shown in the middle of the ü of course). If one types a space now, the result which is committed is first gru "n| (the cursor is always at the end of a commit). Then ibus-typing-booster generates two Left events to move back over the "n which is to the right of the space and the final result is gru |"n where the cursor is just behind the space which was the last character typed.

This works well here, but there might be problems when using input methods like yours where adding a space can change the contents of the preedit before the space.

If you find such problems, feel free to report another bug.

On Wayland this won’t work anyway unfortunately because these Left events seem to be repeated endlessly because of some Wayland bugs.

[rank-coder]

@rank-coder The problem you reported happened when the cursor is at the end of the preedit and you type a space. I think that problem is fixed in https://github.com/mike-fabian/ibus-typing-booster/releases/tag/2.25.12

There might still be problems when a space or a Return is pressed while the cursor is somewhere in the middle of the preedit.

For example, with the m17n input method t-latn-post one might type gru"n| and then the preedit shows grün| where | indicates the cursor position. When one now types Left 2 times the cursor is here in the input gru|"n and in the preedit grü|n (in the preedit the cursor cannot be shown in the middle of the ü of course). If one types a space now, the result which is committed is first gru "n| (the cursor is always at the end of a commit). Then ibus-typing-booster generates two Left events to move back over the "n which is to the right of the space and the final result is gru |"n where the cursor is just behind the space which was the last character typed.

This works well here, but there might be problems when using input methods like yours where adding a space can change the contents of the preedit before the space.

If you find such problems, feel free to report another bug.

On Wayland this won’t work anyway unfortunately because these Left events seem to be repeated endlessly because of some Wayland bugs.

Okay got it. And thank you so much. 💐