fcitx从诞生至今，代码中没有定义一个“候选词”的概念。
同时也没有定义一个“预编辑字符串”的概念（这其实也是fcitx目前不可能实现OnTheSpot的根本原因，虽然我觉得OnTheSpot带来不了什么太多好处，不过不知道为何那些天杀的程序都喜欢和OverTheSpot过不去……）
在提供给界面显示的时候，提供的是两个包含需要显示文本的数组，分别对应候选框的上半文本和下半文本。
现在这个设计终于要成为继续开发的阻碍了。
目前遇到的一个需求就是插入额外候选词，其实关于这点我也想了一些其他办法，比如说单独独立出来显示，或者附加在原有的列表后。（其实单独列出一条，然后用比如`这种键选择对我来说真的没什么大不了的……）
但实际上都为实现带来了不必要的麻烦。
于是决定还是添加候选词的抽象部分。
关于候选框，我见过横的，竖的，却没见过横竖结合的矩形候选框。如果能做个 2×3 或 4×5 的矩形候选框，不知会有什么感觉。减少翻页次数的诀窍还是提升匹配成功率，但最暴力的方法，还是增加候选词的数目。随便说的，不要当真。
@vx13 个人以为2×3之类的有点微妙……
主要问题在于对齐。大概也因此所以大家都懒得实现。
@vx13 紫光拼音有网格状的候选，可以省去翻页的麻烦，不过一般来讲用不太到。
我打赌你下一版绝对没法降低内存占用。现在的迫切需求是降低内存占用。你见过哪个输入法比桌面环境内存占用还大的？
@Mike Ma 我这里fcitx占用12.9M，你那里多少？
@Mike Ma fcitx的词库会直接载入到内存里，所以内存占用多。不过如果内存占用少了硬盘读写就多了，我以为这绝不是什么好事……
另外小词库不会很大，我这里最近版本也就18兆……