What version of the product are you using? On what operating system? OS (Linux distributions, UNIX or ...):

Fedora 14 Architecture (i386, x86_64): x86_64 IBus version: ibus-table-1.3.0.20100621-3.fc14.noarch Input method name and version: https://github.com/pravins/indic-table/tree/master/ibus-table-test Python version: python-2.7-8.fc14.1.x86_64 dbus version: dbus-1.4.0-1.fc14.x86_64 dbus-python version: dbus-python-0.83.0-7.fc14.x86_64 gtk version (if bug is about gtk applications): qt version (if bug is about qt applications):

What steps will reproduce the problem? 1. install db given in https://github.com/pravins/indic-table/tree/master/ibus-table-test 2. type "hy" 3. it should show all the phrases starting with this key 4. scim is doing this very well

What is the expected output? What do you see instead?

Please provide any additional information below.

Comment deleted

Can you reproduce this issue with a recent release of ibus-table?

Hello, I have the same issue on fedora with ibus-table = 1.3.9.20110827

I think you can check the following file: https://github.com/maxiaojun/ibus-table/blob/master/engine/tabsqlitedb.py Comments form line 688 to line 690 explain the mechanism currently used.

Such piece of code is there since the initial commit of ibus-table's git repo.

Issue 1365 has been merged into this issue.

I believe there is something more strange with this. This is more than a "number of candidates matter", but an issue I do not understand. (I might fill a distinct bug report.)

Perfect candidate can be ignored, while other candidates appear. The sqlite request does not seem to be responsible for this. Unfortunately I just discovered this and can only provide below example because I do not understand the principle yet (sorry , tables too big to attach)

• http://py.luyten.fr/ibus-table-wubi-98.db : input "de" or "dee". For the latter, 历 is the only candidate perfectly matching (m0=1 and m1=5 and m2=5 and m3 is null) .Plus, user_freq is 1. But this 历 does not appear.

• http://py.luyten.fr/test.db : this database is a copy of above one. I only removed candidates (all phrases not starting with "d" ...). Now, when I input "de" or "dee" , the 历 candidate appear (for both cases).

I have tested on the latest ibus-table release using your top .db file.

I input "de", the first candidate is 历, which is a perfect candidate. The second candidate is also 历 (with an aux char "e"), which it should be the 历 of "dee". Then followed by all candidates started from "de".

I believe this is now an expected behavior. The case of 历 having both "de" and "dee" combinations is normal in wubi may be, and either of them should not be removed.

The behavior of typing first few keys to pop up a list of candidates that starts from those keys is called "progressive" mode. This should conflicts with "auto commit" mode which any singular match will be commit automatically.

Can my explanations help?

This should be fixed in recent ibus-table.

In recent ibus-table, one can also configure in the setup tool whether one wants to have an automatic multi-character wildcard added after the input string or not. The default is to add and automatic multi-character wildcard.

For example, when * is the multi-character wildcard (this is the default but it can be configured in the setup tool), typing “hy” behaves as if “hy*” has been typed and it matches all phrases starting with “hy”

Please try ibus-table-1.8.4:

https://github.com/kaio/ibus-table/releases/tag/1.8.4

For Fedora users:

https://admin.fedoraproject.org/updates/FEDORA-2014-8161/ibus-table-1.8.4-1.fc20

Setting to “Fixed.”