新引入的四字以上的补全候选，默认排在四字候选前

[mirtlebot]

Describe the bug

script_translator 中，新引入的 4 字以上的候选在输入四个音节时，会出现。

当

• 词典中含有 4 音节组成的候选，
• 而用户词典中含有该 4 音节开头的用户词汇时

补全候选反而会出现在四音节词的前面。

To Reproduce

build librime make and cd build/bin/

1. ./rime_deployer --set-active-schema luna_pinyin
2. rm build luna_pinyin.userdb -rf
3. ./rime_api_console
4. input：shanghaidiqu 一个存在与词典中的四音节词汇 -> 出现「上海地區」候选
5. input：fada，input {space} -> 上屏「上海地區發達」自造词
6. input：shanghaidiqu -> 候选排序为 1. 上海地區發達 2. 上海地區

其他四字音节词汇有相同情况。

1710050902.webm

Expected behavior
未输入完整音节时，补全候选总是排在非补全候选后。正如正常词典候选那样。

Flavor(please complete the following information):
Select your flavor:

• ibus-rime
• fcitx-rime
• fcitx5-rime
• Squirrel
• Trime
• Weasel

Package:

• OS: [Ubuntu 22.04.4 LTS, Windows 11]
• Version: [ librime ec4bdfe, Weasel nightly build]

cc @lotem

大概是 4 个音节以上，补全词在用户词典内，都是这个行为，可能不算是 bug ？但对于 script_translator 来说，倒确实挺反直觉的。

[lotem]

只做到這裏，不會做了，不想做了。
可能做好這塊得寫出詞策略。

討論討論，請給出點兒點子。

如果說四音節優先於長詞補全，有一個不理想的場景：全部輸入簡拼，固態詞典裏四字詞非常多，補全的候選特別靠後，失去了提示的作用。尤其是會讓用戶自造的長詞不容易快速輸入。

相對容易實現的邏輯是：
一、用戶詞典優先於固態詞典；
二、用戶詞典裏的完整匹配的詞優先（未實現）於補全的詞；
三、固態詞典裏完整匹配的詞優先於固態詞典裏補全的詞。

「二」爲啥未實現：
因爲「一」已經會讓長詞補全出現在完整匹配的詞前面了，那還要在乎排在後的詞出自用戶詞典嗎？
並且，也擔心會再舉出反例。比如自己造了一個長詞，輸入前幾個音節，因爲用戶詞典裏有完整匹配的短詞，所以無論這個長詞多常用，都無法讓他出現在第一位；甚至短詞用過的短詞多了，還可能把這個長詞擠出第一頁。

[lotem]

可能要加策略來控制。但這個我還沒想好。咱也不能抄東家的呀。

比方說，可以這樣簡單辦：
用戶詞典的長詞補全，把第一個候選讓給完整匹配的詞。
目前，整句結果會放在第一位，所以長詞的前幾個音節如果詞庫裏沒有完整匹配的詞，這個長詞反而不會成爲首選了。
這一點是目前的實現有矛盾的地方。

[mirtlebot]

librime/src/rime/gear/table_translator.cc

Line 239 in 7470f38

return cand && cand->type() == "completion";

看到 table_translator 给它逐键提示的词加了个 completion 的类型，有没有可能 script_translator 也把这些补全的词也改成 completion，这样倒是可以用 lua 自己加 filter 排序 sentence，phrase 和这类补全的候选。

[lotem]

lua 是一项可选功能。

標註 completion 類型的時刻已經到了 translator 的最後一步。最好還是在離開 translator 之前有合理的排序。

代碼裏 completion 這個類型 reverse_lookup_translator 會看，用來排序的。這樣標記會有什麼影響，得測試。