新的问题
bczhc opened this issue · comments
-
我的方案配置中有一句：
- { accept: space, send: Escape, when: composing } #无候选时（空码）空格清屏
期待是空码时按空格清除空码，无任何其他操作。但是实际它会清码后再上一个空格。按空格时控制台写的是
simulate key sequence:。我开了debug=on，发送apo（apo为空码），就会出现多上一个空格的问题；但发送apo{space}，就正常。看来应该得向librime传{space}。 -
Tab键不映射
- { accept: Tab, send: apostrophe, when: always } - { accept: Release+Tab, send: Release+apostrophe, when: always }
-
左右Alt不映射
- { when: has_menu, accept: Alt_R, send: 3 } # 三选 - { when: has_menu, accept: Alt_L, send: 4 } # 四选
-
dependencies都得在schemas.json中定义出来，这就导致它们都会在方案列表中显现出来，即使它们并不是实际使用的方案。就像这样，那些没中文名的就是辅助方案：
以及感谢对lua的支持！现在我的方案终于能用了，基本所有功能都是正常的，就是上面测试的几个问题。超过我的预想。没想到竟还有环境变量hh
哦还有，我的emoji引导不知道为什么不编码提示了。就emoji引导不行，其他的都可以。
4最简单，你按文档里加disabled: true就行了。
你的schemas.json贴一下我好测。
我这个方案可能有些复杂。不知其他过多不相关的东西会不会影响到。
[
{
"id": "luna_pinyin",
"name": "朙月拼音",
"emoji": true,
"target": "luna-pinyin",
"dependencies": ["stroke"],
"license": "LGPL-3.0-only"
},
{
"id": "stroke",
"name": "五笔画",
"target": "stroke",
"dependencies": ["luna_pinyin"],
"variants": [],
"license": "LGPL-3.0-only"
},
{
"id": "tiger",
"name": "虎码",
"target": "bczhc/rime-demo",
"dependencies": [
"tiger_core2022",
"PY_c",
"emoji",
"html_chars",
"latin_international",
"ipa_yunlong",
"short_punct",
"named_ipa_diacritics"
]
},
{
"id": "tiger_guihu",
"name": "九重鬼虎",
"target": "bczhc/rime-demo",
"dependencies": [
"tiger_core2022",
"PY_c",
"emoji",
"html_chars",
"latin_international",
"ipa_yunlong",
"short_punct",
"named_ipa_diacritics"
]
},
{
"id": "zrm_pinyin",
"name": "自然码+辅助码",
"target": "bczhc/rime-demo",
"dependencies": ["chaizi"]
},
{
"id": "kongmingma",
"name": "空明码",
"target": "bczhc/rime-demo",
"dependencies": []
},
{
"id": "tiger_core2022",
"name": "tiger_core2022",
"target": "bczhc/rime-demo",
"dependencies": []
},
{
"id": "PY_c",
"name": "PY_c",
"target": "bczhc/rime-demo",
"dependencies": ["stroke"]
},
{
"id": "emoji",
"name": "emoji",
"target": "bczhc/rime-demo",
"dependencies": []
},
{
"id": "html_chars",
"name": "html_chars",
"target": "bczhc/rime-demo",
"dependencies": []
},
{
"id": "latin_international",
"name": "latin_international",
"target": "bczhc/rime-demo",
"dependencies": []
},
{
"id": "ipa_yunlong",
"name": "ipa_yunlong",
"target": "bczhc/rime-demo",
"dependencies": ["named_ipa_diacritics"]
},
{
"id": "short_punct",
"name": "short_punct",
"target": "bczhc/rime-demo",
"dependencies": []
},
{
"id": "named_ipa_diacritics",
"name": "named_ipa_diacritics",
"target": "bczhc/rime-demo",
"dependencies": []
},
{
"id": "chaizi",
"name": "chaizi",
"target": "bczhc/rime-demo",
"dependencies": []
}
]左右Alt是在这个地方return掉了，但不是按这里说的，在edit模式下会发送所有keydown。我没办法让它simulate左右Alt。所谓的edit模式是什么？
my_rime/src/components/MyPanel.vue
Lines 222 to 232 in 6e8da57
b754aa5 修复了emoji的问题。在我集成emoji时tips: none还不是默认（这个commit改的），导致每个emoji后面都有文字rime/rime-emoji#24 (comment) ，于是我把emoji后面的comment全屏蔽了。现在默认显示所有comment，提供了hideComment: "emoji"专门屏蔽emoji的comment。
非edit模式下，Tab有明确的转移焦点的默认行为，所以不支持。你可以改代码强行支持。
在onKeydown打一个断点，然后按Tab键，单步执行，就会发现是
my_rime/src/components/MyPanel.vue
Line 228 in ebb8a49
document.activeElement !== textarea || (!isPrintableKey && key !== 'Tab')，就可以把Tab也交给librime。类似的操作也可以在
onKeyup搞一遍，结果是把my_rime/src/components/MyPanel.vue
Line 286 in ebb8a49
(editing.value && isPrintable(key)) || key === 'Tab'好吧，既然
keydown的handler是异步的（因为我让librime跑在worker线程），在第一个await之前必须决定是否prevendDefault，所以只要让librime处理就不可能走默认行为了。
的话，那就只能没法处理非composing模式下的Tab了。
就是在composing模式下，Release+Tab好像没处理。处理下这个就好了。
就是在composing模式下，Release+Tab好像没处理。处理下这个就好了。
可以，5c14af4 处理了。当时过滤是因为onKeyup只是为了宫保拼音加的，没考虑定制需求。
1的话我用KeySequence::Parse空格字符和{space}，效果是一样的。所以问题应该不是发送{space}和 之前的区别。
debug on之后，比如那个虎码的cpo是空码，我在下面发送key的地方输入cpo回车，再输单一一个空格，再回车，这时上方文本框会多出一个空格，非预期行为；但我如果一次性输入cpo_（_是空格），回车，上方不会上那多的一个空格。
不表达那么多，简明的测试例子就是：
a_cpo_b_ -> 来如
但a_cpo, _, b_ -> 来 如
它们俩应是一样的，即来如
空格是在这里上屏的：
my_rime/src/components/MyPanel.vue
Lines 162 to 168 in 5c14af4
写着REJECTED，但事实上这里空格应该是被消费的，也就是RimeProcessKey会返回True，所以这里不应该来到这个if分支。
我不太懂Emscripten WASM和前端，似乎没看到Module.ccall('process', ...相应的C函数？而且rime_api好像也并没有一个叫process的函数吧。本来就是想看一下这个process的返回值是哪里构建的，据我看的librime源码，RimeSimulateKeySequence好像不能直接从它的返回值得知是否被processors消费掉，741行的返回值并没有使用，返回False只是代表着Parse失败：
https://github.com/rime/librime/blob/d0d227c70daa25c9671e8355b042c0c1697c2de4/src/rime_api.cc#L730-L744
只有RimeProcessKey可以反映出：
https://github.com/rime/librime/blob/d0d227c70daa25c9671e8355b042c0c1697c2de4/src/rime/engine.cc#L96-L115
process定义在
Line 7 in 5c14af4
到这里还是在主线程。我把worker通信逻辑（postMessage）封装在了https://github.com/LibreService/my_worker
然后这里就已经是worker线程了
Lines 91 to 93 in 5c14af4
ccall能调的函数要么是被
EMSCRIPTEN_KEEPALIVE修饰，要么是在emcc/em++时显式export my_rime/scripts/build_wasm.mjs
Line 38 in 5c14af4
最终找到https://github.com/LibreService/my_rime/blob/master/wasm/api.cpp ，封装了librime，把结果以json形式传给前端。
哦看到了。刚才IDEA发毛病了，全局搜索没搜到。似乎不应以是否commit了来判断key event是否被消费掉？
我也试着写了个rime-tui，就是用的之前我说的，如果processors没处理再执行默认行为。用的就是RimeProcessKey。没有问题。
https://github.com/bczhc/rime-tui/blob/cc5c7894c48bf8fe4b15fe49c962bb5f8c9948e2/src/main.rs#L85-L99
https://github.com/bczhc/librime-rs/blob/8b745820b8b28d7a007f436605f3bcc882ede72e/src/lib.rs#L129-L132