居戎氏
预期结果是「嫌弃啊」？
需要加一个API函数。我记得讨论过，现在看代码好像还没加。
尚未實現。 https://github.com/lotem/rimeime/issues/27 ：我怎覺得，如果不是爲了在輸入時能用上數字鍵而必須將選字模式分開，怎麼看都是直接出候選字更便利。
@osfans 請注意並不是簡單地不顯示候選字。 其本質是編碼輸入模式和選字編輯模式這兩個互斥模式的切換。類似 Vim 的模式。 `editor` 裏面 `toggle_selection` 這個行爲只能粗略模擬傳統注音輸入法空格鍵的操作習慣。我對這個功能不太滿意。從此就耽擱了後來的發佈。
思路很好。 實現方法可以改進。
跨音節拼寫運算的問題的確值得研究。 現在 Rime 沒有支持這項功能，因爲我對這個問題的認識有限，不夠自信能作出足夠通用、能解決一類問題的程序。 變調在漢語方言中普遍存在。輕聲也許可以看作類似性質的問題。 官話等方言的兒化韻（還包括子變韻、合音詞）屬於另一種情況，涉及音節數目的增減。 還有人提到其他語言的，如泰文，也有跨音節處理的需求。 可以肯定的是，以平臺支持這項功能，比實現單獨一例難度要高。 作用於單個音節的拼寫運算，也不算很簡單，但至少定義和用法已經很明確了。 跨音節要怎麼做，我還沒有想周全。 另一番討論 https://github.com/rime/librime/issues/85 ，提出一種不同思路，即將輸入串變形後再查詢。這種思路難點在於應對輸入串到字典編碼的轉換有歧義的情況。 `Encoder` 固然是用來註音的，但必須用他的場合其實是在打字的時候爲用戶輸入的新詞編碼。 而預先準備好的詞典，我們有時間，可以利用各種手段完成註音。未必要用 Rime 的編碼器——這種場合他只爲詞典製作者提供些許方便，然而是可替代的——如果詞典文件已經完成編碼，就不需要動用。 我想說明：使用外部工具或腳本生成註音，未必構成「濫用」。無論在內存中完成編碼（註音）還是在外存（詞典文件）完成，最終結果是一致的，即寫入 `.bin` 文件的是全部已註音詞條。 惟一可能構成問題的用法是，人工標記的詞條與工具生成的數據混同在一個文件裏。這可以通過引入額外的處理步驟解決：詞典源文件→用外部工具生成註音→結果存入中間詞典文件→ 由 Rime 讀取並轉換爲固態詞典。添加這個中間步驟另有好處：可以不受 Rime 功能限制，實現任意有針對性的轉換規則。 總之，凡是可以前期處理的數據，我傾向於在 Rime 之外做預處理。這也符合讓程序專注於一項任務、組合多個程序完成複雜功能的...
從軟件的角度沒什麼障礙。 無論定製輸入法詞典中的用字，還是定製OpenCC轉換詞典實現一套新的用字標準，抑或將二者結合，都已有現成的解決方案。 OpenCC已經內置多種漢字轉換標準： https://github.com/BYVoid/OpenCC#%E9%A0%90%E8%A8%AD%E9%85%8D%E7%BD%AE%E6%96%87%E4%BB%B6 用家根據對文字的需要和理解，收集整理數據即可。依我的理解，這些工作不需要輸入法軟件開發者的配合與協助。
> 同样的问题。2k分辨率，Arch Linux。 > 在Firefox、Chrome、Edge里候选词框向下偏移 不是同樣的問題。
預期效果是怎樣的？ ibus-rime 使用默認鍵盤佈局： https://github.com/rime/ibus-rime/blob/d525f18b45123869af0055cc8402d459ebdbb9e3/rime.xml.in#L19
估計小狼毫算法服務進程被優化掉了吧。圖標是輸入法前端顯示的，不在輸入法的進程裏。