librime手动排序功能开发说明前述 #1105
Description
背景：
在很多时候单一编码下面会出现很多候选，在常规自动调频的作用下，我们常常无法固定在哪、在那这样的词汇位置，也因此常常打错。在行业输入中，日常词汇：“老是” 和 校园词汇“老师”常常面临着谁在前的问题，其他行业同样面临这个问题，这受到生活环境、等多方面的影响。另一个方面是方案作者，形如万象这样200万词汇的方案，要关注每一个音节组的排序、要关注分词结构，压力全部给到了维护者，费心费力选出的那个首选，可能也仅仅代表了部分人意愿，无法满足千人千面。那么能不能共建？能不能看见错词、分词结构不对的立马冻结储存起来，后续批量提交给作者呢？对于用家，能不能经过长期使用沉淀下来自己的固定频率？其实很多时候每个人使用词汇的范围不大且基本固定，是可以圈定出稳定的范围的，只是每个人的交集不一样。那么如何解决这个问题呢？
万象拼音的策略是手动排序+固定词频，在处理器阶段获取按键事件，按下一次记录一次方向的偏移，储存在userdb中，在滤镜阶段中将这个偏移数据翻译出来，呈现到用家面前，目前已经Lua实现用了很久了。
https://github.com/amzxyz/rime_wanxiang/blob/wanxiang/lua/super_sequence.lua
但同样存在一些问题：
1、单字母输出时，时间复杂性高，Lua无法支撑，从而表现为卡顿，两字母以上无感知
2、用户数据的多设备同步、复用，万象虽然模拟了合并逻辑按照时间优先和删除的墓碑机制，但用家还是有很多人理解不了用法，且平台差异性较大，如ios app中不能简单的Lua读写，涉及到键盘文件与应用文件的交互。
3、Lua长期占用userdb，无法放在根目录复用userdb的数据结构和同步逻辑，放在根目录这会导致同步报错文件锁，如果断开则严重影响效率根本没法用
解决方案：
在长期的实践中，看到不管是五笔、拼音用户都有调整候选位置的需求，存在需求的共性
那么我们应该考虑将功能实现沉淀到librime，一方面是原生优势，一方面打破调频与用户词紧耦合的短板。从技术上可以在关闭用户词的状态下，自动启用手动排序能力，复用userdb能力，复用同步用户词库的能力，代码只需要专心实现按键捕获和滤镜翻译即可，对librime原始代码结构无干扰、对稳定性无影响，综上所述，该功能具备整合到librime的条件
需求和注意得点：
1、复用userdb 需要使用 c d t几个字母来构建排序逻辑中的数据结构，而不能使用Lua中现有的字母，首先弃用d t两个参数，这两个参数受同步控制相关联，我们只需要对用户词同步逻辑改造，即可记录下来信息，并在归零的时候直接取-也就是前面加上负号，按时间排序则能做到指哪打哪前后更替的灵动的排序。编码使用原始input,但如果有接口可以获得原始编码如万象使用全拼作为编码，当使用双拼更换双拼则这个值不变，能保证数据的完全复用，因此可以设定排序的编码键使用input或者 comment，如能做到不受注释格式化配置影响，能稳定获取到原始comment 即原始编码则应使用这个来作为code,我们需要code+text作为组合键
2、对高亮词汇操作，为不干扰各种方案，默认应设置双修饰键，上移(左移) ctrl+shift+j 下移(右移) ctrl+shift+k 重置 ctrl+shift+l 置顶 ctrl+shift+p 低频场景叠加高亮跟随双手操作也没问题。
方案文件中可定义
sequence_adjuster:
up: Control+j
down: Control+k
reset: Control+l
pin: Control+p
3、注意将高亮与移动步调一致，最新的librime支持高亮跟随，就可以持续按下移动而不会重置到第一候选
需要研究ctrl +del，ctrl+k默认等同ctrl del，对复用了userdb数据库的排序数据的影响，是否会被按c<=0被标记，如何规避。