Closed mike-fabian closed 2 years ago
This happens when for example when:
:
is used at the emoji trigger key:frog
☑ Off the record mode
is on) that commit is saved to to the user database:frog
againNow the candidate list shows something like
1 :🐸
2 :frog
3 :frogman
4 :frogmen
5 :frogging
6 🐸 frog face
And if one selects and commits candidate 1, then :🐸
is committed instead of only 🐸
.
This is probably not wanted.
As a workaround one could use the option ☑ Off the record mode
to avoid saving anything to the user database (And clear the user dababase with “Delete learned data” if it is already not empty anymore).
But doing this would be terrible if one wants to use ibus-typing-booster for anything else but emoji, using it for “normal” language off course cannot work well without learning from what the user typed.
Even when one is only interested in emoji, using ☑ Off the record mode
prevents ibus-typing-booster from learning which emoji have been used often and put them up higher in the candidate list. I.e. without using the user database, each search for emoji will give the emoji candidates in exactly the same order without learning from previous use.
This is not so bad because ususally there are not so many emoji matching a particular search string, so if one uses ibus-typing-booster only for emoji, this might be “good enough” already. But there is certainly room for improvement.
Now it works without duplication and ibus-typing-booster correctly changes the priority of the emoji according to which was typed most often:
https://user-images.githubusercontent.com/2330175/168567944-a63f8893-c968-40b9-b999-d82efc384334.mp4
See screenshot: