新的问题
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中定义出来,这就导致它们都会在方案列表中显现出来,即使它们并不是实际使用的方案。就像这样,那些没中文名的就是辅助方案:
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