Make it possible to recover from errors when “Auto wildcard” is off and typing more characters produces valid input again

[mike-fabian]

#70 (comment)

I am thinking about some corner cases here. For example the cangjie5 table contains:

djlv 棲 1000
djmbc 𩑷 1000
djmc 檳 1000
djmc 𣠦 1000

I.e. there is the code djmbc for 𩑷 but there is no character which has exactly the shorter code` djmb.
As long as the “Auto wildcard” option is used, this is no problem, one can type just “djmb” and as a wildcard is silently added what is actually looked up is “djmb*” which matches “djmbc” so there is no error.

But when the “Auto wildcard” option is switched off, it becomes impossible to type 𩑷 because typing djmb already produces an error and beeps and adding the final c does not help to recover from the error.

I consider this a bug which I should fix.

Currently switching off the “Auto wildcard” option in cangjie5 has the effect that some characters cannot be typed anymore.

I probably should try to make it possible to recover from such errors, i.e. typing djmb would still beep and display the last character in the preedit in a different colour, but adding the b would not beep and the preedit would be all the same color again.

It seems to me that it would be utterly confusing for users to get the error message and then be able to continue typing as if nothing happened.
So maybe just remove turning off the 'Auto wildcard' option for cangjie? I can't think of any reason why anyone would want to disable it. It only adds value but doesn't create any inconveniences.

[mike-fabian]

Yes, maybe you are right, thinking about it...

By the way, I noticed some strange behavior from ibus-table, but I'm not sure if I should open an issue over it. Remember how illegal input will be colored pink (or violet? idk i'm not good with colors lol)? Well that doesn't work in some applications, for example, in LibreOffice or in Skype. It works in Firefox and Telegram, though. Not sure why that is so. Does it have something to do with GTK vs Qt perhaps?

[mike-fabian]

By the way, I noticed some strange behavior from ibus-table, but I'm not sure if I should open an issue over it. Remember how illegal input will be colored pink (or violet? idk i'm not good with colors lol)? Well that doesn't work in some applications, for example, in LibreOffice or in Skype. It works in Firefox and Telegram, though. Not sure why that is so. Does it have something to do with GTK vs Qt perhaps?

That effects all ibus input methods and I cannot really do anything about this.

In some toolkits/environments, using colours in the preedit doesn’t work. In some toolkits even the underlining of the preedit cannot be controlled.

This is also the case when using Wayland, for example Gnome running in Wayland. Then the preedit always has a single underline and always has the default foreground and background colours and the requests by ibus engines to set these styles are just ignored.

See for example this discussion about Gnome/Wayland:

https://gitlab.gnome.org/GNOME/mutter/-/issues/153

If you look at my screenshots in this issue, you see example for the Japanese input method ibus-anthy, ibus-typing-booster, and ibus-table, all using colours and changing the underlining to give some extra information about the preedit. The screenshots are done on Gnome Xorg, on Gnome Wayland this doesn't work.

When using Gnome under Xorg, the styles in the preedit work, in Gnome Wayland they do not.

[mike-fabian]

In ibus-typing-booster, I use both colours and underlining/no-underlining to indicate inline completion.

As neither works in Gnome Wayland, the “inline completion” option of ibus-typing-booster is very hard to use in Gnome/Wayland.

[mike-fabian]

I also use the flashcard program anki, which uses Qt5. There the preedit styles do not work either.

Same in Libreoffice, as you noticed.

So these bugs should be reported against Qt, Libreoffice, Wayland, ... the ibus engines cannot do anything about that, unfortunately.