Mike FABIAN

I mean the speed issues of the user having to select from too many matches. For example, “hm” could match “him”, “ham”, “hum”, “home”, “hame”, “ohm”, ... and probably many...

> @mike-fabian @infokiller I have extracted the Android auto-suggestion and correction library from the last open source release of the Android (now Google) keyboard. It is basically a C++ library....

Factoring in the keyboard layout is more difficult on the desktop because you don't know what the keyboard layout actually is, usually.

The current approach is not only hunspell, that is a sort of last ditch fallback if no learned data is available yet. And of course hunspell gives spellchecking suggestions. Preditions...

Some keyboards like the French one for example are very different.

On Fedora, the Korean hunspell dictionary was recently updated and therefore I had to adapt the test. Probably, FreeBSD still has the old Korean dictionary.

See: https://github.com/mike-fabian/ibus-typing-booster/commit/ca0ecc31567fa0333dda71c9145ff45d0b1ac2c3

That change was already in ibus-typing-booster 1.5.37 though. Did the test case still work for you in ibus-typing-booster 1.5.37?

The comment at the start of the Korean test case says that there is no Korean hunspell dictionary on FreeBSD and therefore the test is skipped: def test_korean(self): if not...

And, the testcase ues the 'ko-romaja' input method. Do you have it available? On Fedora it is in this package: $ rpm -qf /usr/share/m17n/ko-romaja.mim m17n-db-1.8.0-3.fc28.noarch