Lantaio Joy

@shewer 大神你好。你的意思是我在if语句体里面的思路或者说写法是不对的？但我是参考你放在这个仓库的`component_test.lua`示例代码而想到的啊。你的示例是用for循环去让按键事件遍历全部的`Processor`处方。莫非按键事件是不能在程序里面创建出来的？还是说我的创建方式不对？ 至于你说的segmentor、translator和filter这些，因为我只是处理1个退格键，所以按我的理解是不需要这些后续处理的，我看了rime wiki的理解是，这个按键在processor阶段已经上屏并结束1个分析流程了。segmentor和translator这些只有在处理像拼音这种有候选框的输入情况时才会用到吧？不知道这样理解对不对。比如说如果按Shift键切换到英文模式的时候，这时按英文字母按键会由processor组件的第1个处方ascii_composer来处理并上屏，然后就结束分析流程了，不会往下走segmentor处理和translator处理，甚至连后面的processor处方都不会走了。 不过我刚测试过，将退格键改为一个小写英文字母，然后改为让`ascii_composer`去处理这个按键事件，也不行，没有得到预期的效果。那估计我这样写是不行的了。至于你说的`commit_text`已经试过，不理想，`commit`是上屏候选词用的，连参数都没有，更加不适用。我再搜索一下看看有没有新发现吧，多谢大神。

感谢 @shewer 大神进一步的解释说明。你所说的处理原理和流程虽然我之前略懂，不过经你这么一说，觉得自己之前自己的考虑太片面了。我之前总是一心想着能发送退格键给Rime处理就行了，并不关心返回值是什么。现在觉得还是要仔细了解Rime的处理流程和原理。之前的理解是Rime应该在某个processor处理退格键，并返回`kRejected`不作处理让系统按默认方式处理退格键。现在想想即便是这样返回，正如你所说可能也只是返回到a这一层，没有最终退出处理来将退格键交给系统处理。而后面继续处理a的时候b已经丢失了。这样确实很棘手。

如果真如 @hchunhui 大神所说的话，那我想实现的功能就死翘翘了。本来还冒出个想法看看能否直接将`key`替换为退格键的，但又想到`key`参数好像是作为常量定义的，那就又碰壁了。

最近想实现一些功能，还是得先实现发送退格键这个功能才行。虽然上面 @hchunhui 大神说的librime工作原理可能是这样，但好像也不尽然是这样，不是可以通过`commit_text`向系统发送任意数量的字符吗？所以说不仅仅是对按键做翻译工作啊。另外我还看到有个`env.engine.process_key(keycode)`方法，虽然之前折腾不成功，不过感觉有可能通过它来实现发送退格键的功能。 虽然我现在也在寻求AutoHotkey或者nircmd这些第三方工具来实现这个功能，但一来还没有折腾出来，二来就算折腾出来了，在发送退格键的时候也可能会有个黑色的cmd窗口闪一下，既不美观，也浪费系统资源。 我看看能否请 @lotem 大神解决这个问题，我还大神一个更懂大神的输入法！😁

最近2个月折腾AutoHotkey，给我折腾出想要实现的功能了，而且貌似比单用Rime来实现更好。所以不麻烦 @lotem 大神来折腾这个功能了。迟些等项目完成得差不多，开源的时候再告诉大家。再次感谢各位大神热心相助🤝

对了，还有一个问题，就是此预测项目的设计理念是怎样的？是在输入（上屏）一个词组之后，自动预测下一个可能要输入的词组并显示候选菜单？还是在输入的时候，根据前一个已经上屏的词组来对正在输入的候选项进行优化排序？

十分感谢 @lotem 大神的回复。不过我仔细测试过，即使我用最简单的`luna_pinyin.custom.yaml`文件来添加预测功能，都没有任何效果，上屏字词后不会自动弹出联想词候选菜单哦。如果有时间请帮我看看[测试方案](https://github.com/Lantaio/Rime-schema-JoySchema/blob/dev/luna_pinyin.custom.yaml)有没有什么问题？我还没有上传`predict.db`文件到GitHub，但在本地用户目录是有的。初步估计可能还缺少某些依赖？ 还有就是我现在安装的小狼毫不是2023年6月6日的0.15.0版，是最新的Release，Rime版本是1.10.0的，不知道有没有影响。 另外，此预测功能是否仅限于繁体中文？简体中文能否使用？

对了，如果是缺少运行时依赖的话，是不是需要安装某个版本的C++运行库？又或者是某个版本的.NET运行库？

我的情况是繁体字也没有任何效果哦。