Open huangyxi opened 1 year ago
例如在 Mac 鼠须管前端中无论将快捷键
Alt+a
配置为a
的send
功能 还是send_sequence
功能,输出的均为带有 accent 的字符å
。特性说明
希望增加一个功能,例如在
key_binder/bindings
下设一个commit
功能,使得通过组合健能直接将字符上屏,而不是模拟按键的输出,例如使用⌥/alt + a
直接上屏小写字母a
,或者其他任意字符。
{ when: composing, accept: Alt+a, send_sequence: "a{Return}" }
其一是如果输入的英文字符串中被输入法以空格分词,则
commit_code
上屏会造成 IDE / 浏览器的提示行为不同
不用上屏,直接鼠标点浏览器的提示项
其二是切换为西文后,如果再切回中文需要多按一次按键,打断输入过程。
默认回车键上屏输入码且不会切换成ascii
{ when: composing, accept: Alt+a, send_sequence: "a{Return}" } 感谢回复。但是测试了一下,Mao 鼠须管中无论是
when: composing
还是when: always
仍然无法在输入⌥ + a
的情况下直接上屏a
。
如果說,按組合鍵,上屏指定的任意Unicode字符串,我覺得這個功能有意義,是現有機制不容易做到的。
單說要用快捷鍵直接上屏英文小写,不太理解使用的場景。總感覺不是最好的實現方法。
又仔細讀了一遍原題中的背景介紹。 要說錄入單個字母取得提示,發個組合鍵是挺快。但這裏有兩個破綻: 一是有的自動補全提示場景,需要繼續輸入多個字母才能定位到想要的選項,那麼連續發快捷鍵就不像單發那樣操作便捷了。 二是發組合鍵要事先想到這個場景要讓字母上屏,先在顱內切換好輸入方式,再指揮雙手做出一套與平時輸入字母不同的動作,心智負擔蠻大。
會不會有更自然,同樣快速,且適應更多場景的操作方式呢。
我看,輸入字母序列後按一個表示字母原樣上屏的功能鍵就不錯,比如很多方案裏配置的 Return 或是 Shift+Return。字母較多時依舊操作便捷,沒有提前想到切換也能在輸入字母後補救,他最大的好處是不改變已經習慣的字母輸入方式,無需任何適應性訓練。其侷限僅僅是和一些形碼的自動上屏功能有衝突。
感谢开发者有耐心从用户的场景理解需求。
对于本人之前的背景描述,开发者给出了 Return
或 Shift + Return
的解决方案。从中文输英文的角度来看,这样的输入方案确实是最自然。这里我想提供以下我为什么想到通过组合键来实现小写上屏的特性。
在英文输入环境中,我们默认输入的是小写。如果遇到少量的连续大写字母,我通常是左手小拇指按住 Shift
然后敲击键盘直接上屏大写字母。于是在默认输入是中文的环境中,我会尝试通过小拇指按住一个修饰健,比如 Shift
。但是 Shift + 字母
已经用于上屏大写字母了,所以想使用一个其他的修饰健来在中文输入环境下直接上屏小写字母。
另外补充一个由于 Return
或 Shift + Return
上屏英文那字母造成浏览器提示行为不同的实际情况。
对于浏览常用网页,我习惯直接输入网址而不是通过搜索引擎搜索进入,相信也有许多用户也是这样的习惯。以“百度”为例,我需要在浏览器输入 baidu.com
,此时如果是英文模式,那么在输入 baidu
的时候浏览器会直接提示进入 baidu.com
,然后通过 Return
可以直接进入网页。
现在,如果输入模式是中文,则在输入 baidu
的时候,输入法会将屏幕上的字母自动分词成 bai du
,如果此时没有其他操作,Chrome 浏览器会提示使用默认搜索引擎搜索 bai du
。如果现在按 Shift
或 Return
,中间的分词的空格会消失,但是浏览器不会提示进入 baidu.com
,而仍然是提示搜索 baidu
。
当然这个是浏览器至少是 Chrome 的陈年老毛病了,问题应该不在输入法,但是还有其他软件是依赖字符更新来触发提示的 浏览器 / IDE 也有同样的烦恼。
{ when: composing, accept: Alt+a, send_sequence: "a{Return}" } 感谢回复。但是测试了一下,Mao 鼠须管中无论是
when: composing
还是when: always
仍然无法在输入⌥ + a
的情况下直接上屏a
。
https://github.com/rime/librime/assets/14979243/a35056f6-2a82-4202-bb90-6ef067a5894d
當且僅當⌥ + a
爲dead key時快捷鍵無效,因爲系統仍在等待用戶輸入被dead key修飾的鍵
感谢开发者有耐心从用户的场景理解需求。
对于本人之前的背景描述,开发者给出了
Return
或Shift + Return
的解决方案。从中文输英文的角度来看,这样的输入方案确实是最自然。这里我想提供以下我为什么想到通过组合键来实现小写上屏的特性。在英文输入环境中,我们默认输入的是小写。如果遇到少量的连续大写字母,我通常是左手小拇指按住
Shift
然后敲击键盘直接上屏大写字母。于是在默认输入是中文的环境中,我会尝试通过小拇指按住一个修饰健,比如Shift
。但是Shift + 字母
已经用于上屏大写字母了,所以想使用一个其他的修饰健来在中文输入环境下直接上屏小写字母。另外补充一个由于
Return
或Shift + Return
上屏英文那字母造成浏览器提示行为不同的实际情况。 对于浏览常用网页,我习惯直接输入网址而不是通过搜索引擎搜索进入,相信也有许多用户也是这样的习惯。以“百度”为例,我需要在浏览器输入baidu.com
,此时如果是英文模式,那么在输入baidu
的时候浏览器会直接提示进入baidu.com
,然后通过Return
可以直接进入网页。 现在,如果输入模式是中文,则在输入baidu
的时候,输入法会将屏幕上的字母自动分词成bai du
,如果此时没有其他操作,Chrome 浏览器会提示使用默认搜索引擎搜索bai du
。如果现在按Shift
或Return
,中间的分词的空格会消失,但是浏览器不会提示进入baidu.com
,而仍然是提示搜索baidu
。当然这个是浏览器至少是 Chrome 的陈年老毛病了,问题应该不在输入法,但是还有其他软件是依赖字符更新来触发提示的 浏览器 / IDE 也有同样的烦恼。
輸入baid
四個字母的時候應該意識到ascii mode錯配了吧?這時候按⇪
/⇧
/⌃
(視乎你的設定)臨時切換ascii mode(commit_code),多半網址就直接補全了。這樣不更符合輸入邏輯嗎?
按照 Chrome 补全的机制,输入 baid
之后临时切换 ascii mode 会提示使用 Google 搜索 baid
,而不是补全 baidu.com
。 (如果浏览器之前访问过 baidu.com
)
这种浏览器 / IDE 的提示机制造成的错误匹配是本人希望加入该特性的主要原因之一,另外一个小问题就是临时切换 ascii mode 模式会导致输入体验的不连贯,回到正常中文模式还需要额外切换,即增加两个多余的按键。
关于输入逻辑的事情,本人认为不同用户会可能有不同的偏好倾向,例如 Vi 系编辑器区分不同模式 mode (normal / insert / visual ...) 来区分正常输入和执行功能,nano / Emacs 等编辑器使用组合快捷键来区分正常输入和执行功能。从这个视角看,使用 ⇪/⇧/⌃
切换 ascii mode 类似于 Vi 系编辑器区分不同输入模式,而使用组合键直接上屏英文就类似于 nano / Emacs 等编辑器直接执行功能。
另外,我们换一个视角,同一个用户在不同场合可能也有不同的偏好。例如 Vim 使用者即便在大段文字输入时习惯用不同模式来区分不同状态,但这也不妨碍这些用户在 bash 等少量文字输入的 shell 中使用 Emacs 风格的输入方式。这就类似与在大段英文输入的时候,会选择 ⇪/⇧/⌃
切换:
当最终上屏字符数 $c$ 较多时,此时输入有效率 $\eta(c)$ 接近 100% 即 $\lim_{c \to +\infty} \eta(c) = 1$,其中
$$\eta(c) = \frac{\text{上屏字符数}}{\text{按键次数}} = \frac{\text{上屏字符数}}{\text{上屏字符数} + \text{开启 ascii mode} + \text{退出 ascii mode}} = \frac{c}{c+2};$$
而如果当输入字符数 c
较少时,仍然采用 ascii mode 输入英文,此时输入有效率 $\eta(c) \ll 1$。
如果在最终上屏字符数 $c$ 较少的时候使用组合键直接上屏,尽管含修饰健的按键数量是最终上屏字符数 $c$ 的两倍 $2c$,但由于组合键的修饰健和拉丁字符是同时按下的,以输入时间衡量有输入有效率仍然为 100%。
按照 Chrome 补全的机制,输入
baid
之后临时切换 ascii mode 会提示使用 Google 搜索baid
,而不是补全baidu.com
。 (如果浏览器之前访问过baidu.com
)这种浏览器 / IDE 的提示机制造成的错误匹配是本人希望加入该特性的主要原因之一,另外一个小问题就是临时切换 ascii mode 模式会导致输入体验的不连贯,回到正常中文模式还需要额外切换,即增加两个多余的按键。
关于输入逻辑的事情,本人认为不同用户会可能有不同的偏好倾向,例如 Vi 系编辑器区分不同模式 mode (normal / insert / visual ...) 来区分正常输入和执行功能,nano / Emacs 等编辑器使用组合快捷键来区分正常输入和执行功能。从这个视角看,使用
⇪/⇧/⌃
切换 ascii mode 类似于 Vi 系编辑器区分不同输入模式,而使用组合键直接上屏英文就类似于 nano / Emacs 等编辑器直接执行功能。另外,我们换一个视角,同一个用户在不同场合可能也有不同的偏好。例如 Vim 使用者即便在大段文字输入时习惯用不同模式来区分不同状态,但这也不妨碍这些用户在 bash 等少量文字输入的 shell 中使用 Emacs 风格的输入方式。这就类似与在大段英文输入的时候,会选择
⇪/⇧/⌃
切换: 当最终上屏字符数 c 较多时,此时输入有效率 η(c) 接近 100% 即 limc→+∞η(c)=1,其中 上屏字符数按键次数上屏字符数上屏字符数开启退出η(c)=上屏字符数按键次数=上屏字符数上屏字符数+开启 ascii mode+退出 ascii mode=cc+2; 而如果当输入字符数c
较少时,仍然采用 ascii mode 输入英文,此时输入有效率 η(c)≪1。如果在最终上屏字符数 c 较少的时候使用组合键直接上屏,尽管含修饰健的按键数量是最终上屏字符数 c 的两倍 2c,但由于组合键的修饰健和拉丁字符是同时按下的,以输入时间衡量有输入有效率仍然为 100%。
https://github.com/rime/librime/assets/14979243/66ea5588-0bef-4ec8-ab0d-df0669ddbfdb
Screen.Recording.2023-09-04.at.09.55.13.mov
應該是你用baidu.com
完整URL的次數還不夠,搜索的優先級比較高
應該是你用baidu.com完整URL的次數還不夠,搜索的優先級比較高
对于浏览常用网页,我习惯直接输入网址而不是通过搜索引擎搜索进入,相信也有许多用户也是这样的习惯。以“百度”为例,我需要在浏览器输入
baidu.com
,此时如果是英文模式,那么在输入baidu
的时候浏览器会直接提示进入baidu.com
,然后通过Return
可以直接进入网页。
事实上,以 ASCII 模式单独输入 baidu
,Chrome 能够将 baidu.com
列为第一候选,而在中文模式下则不行。除了 baidu.com
之外,一切以拼音或存在类似拼音音节的网址,只要输入法中没有对应英文条目都有可能出现上述问题,如 tieba.baidu.com
,niconico.jp
, bilibili.com
等等大量中文互联网网址。
举 Chrome 中网址输入的例子的初衷是为了在一个普遍的场景下方便复现,以及论证该现象的存在性,而在 VSCode 协同 LaTeX 中文写作的场景下该现象还会更加普遍。
應該是你用baidu.com完整URL的次數還不夠,搜索的優先級比較高
对于浏览常用网页,我习惯直接输入网址而不是通过搜索引擎搜索进入,相信也有许多用户也是这样的习惯。以“百度”为例,我需要在浏览器输入
baidu.com
,此时如果是英文模式,那么在输入baidu
的时候浏览器会直接提示进入baidu.com
,然后通过Return
可以直接进入网页。事实上,以 ASCII 模式单独输入
baidu
,Chrome 能够将baidu.com
列为第一候选,而在中文模式下则不行。除了baidu.com
之外,一切以拼音或存在类似拼音音节的网址,只要输入法中没有对应英文条目都有可能出现上述问题,如tieba.baidu.com
,niconico.jp
,bilibili.com
等等大量中文互联网网址。举 Chrome 中网址输入的例子的初衷是为了在一个普遍的场景下方便复现,以及论证该现象的存在性,而在 VSCode 协同 LaTeX 中文写作的场景下该现象还会更加普遍。
https://github.com/rime/librime/assets/14979243/a65dcb3f-9337-4d38-b26a-f827480f70d3
完全無法複現你所提到的情況。才輸入五六次就已經首字母直接補全網址了。回車上屏已輸入的網址且不切換ASCII,再回車打開網站。比什麼組合鍵輸入小寫要方便得多吧?何況網址不區分大小寫,你也完全可以capslock
请问阁下输5、6次之前有出现过没有补全网址的情况么?
回車上屏已輸入的網址且不切換ASCII,再回車打開網站。比什麼組合鍵輸入小寫要方便得多吧?
请详见数学分析 https://github.com/rime/librime/issues/686#issuecomment-1694127370 。
请问阁下输5、6次之前有出现过没有补全网址的情况么?
當然有啊,chrome的設計就是這樣的啊,是否補全網址取決於近期是否高頻登入該網址
回車上屏已輸入的網址且不切換ASCII,再回車打開網站。比什麼組合鍵輸入小寫要方便得多吧?
请详见数学分析 #686 (comment) 。
然而直接回車並非切換ascii模式,此時 $$\eta(c)=\frac{c}{c+1}$$ 理論上和你提出的組合鍵輸入效率相同,實際上因爲不破壞輸入的手型,效率是高於你的組合鍵方案的
P.S.修飾鍵與主鍵並非同時按下,而是先按修飾鍵然後在未抬起修飾鍵的情況下按下主鍵。平均耗時必定超過按兩個字母鍵(按鍵位置越偏遠耗時越久;加上組合鍵按下的時間必須重疊的要求,導致絕大多數情況下都是先抬起主鍵,後抬起修飾鍵,所以即便不考慮修飾鍵的偏遠位置和對輸入手型的破壞,耗時都應該至少是按兩鍵)。
平均耗時必定超過按兩個字母鍵(按鍵位置越偏遠耗時越久;
实际上本人使用 shift
输入大写拉丁字母的效率几乎等同于输入输入小写拉丁字母的效率。即便左手小拇指(little finger)按下 shift
的同时无名指(ring finger)敲击其他字母的时间也仅仅略长于仅敲击小写拉丁字母(约0.2x),右手敲击右手区大写拉丁字母的时间更是接近直接敲击小写拉丁字母。
然而直接回車並非切換ascii模式,此時... ...按鍵位置越偏遠耗時越久...
在 QWERTY 布局中,比起右手默认键位 ;
与 return
的距离,左手默认指位 A
与左 shift
的距离要更加接近,耗时也必定越少。
平均耗時必定超過按兩個字母鍵(按鍵位置越偏遠耗時越久;
实际上本人使用
shift
输入大写拉丁字母的效率几乎等同于输入输入小写拉丁字母的效率。即便左手小拇指(little finger)按下shift
的同时无名指(ring finger)敲击其他字母的时间也仅仅略长于仅敲击小写拉丁字母(约0.2x),右手敲击右手区大写拉丁字母的时间更是接近直接敲击小写拉丁字母。然而直接回車並非切換ascii模式,此時... ...按鍵位置越偏遠耗時越久...
在 QWERTY 布局中,比起右手默认键位
;
与return
的距离,左手默认指位A
与左shift
的距离要更加接近,耗时也必定越少。
主鍵盤區敲兩個字母鍵的用時也可以很接近敲一個鍵的用時。真要較真,
Screen.Recording.2023-09-04.at.09.55.13.mov
你這不明明才輸入b
就已經補全baidu.com
了嗎?所以你到底在抱怨甚麼?
主鍵盤區敲兩個字母鍵的...
前文(https://github.com/rime/librime/issues/686#issue-1838764597, https://github.com/rime/librime/issues/686#issuecomment-1675995592 ,https://github.com/rime/librime/issues/686#issuecomment-1694127370 )已大段阐述使用修饰健直接输入拉丁字母的动机以及背景,此处不再赘述。输入习惯本来就因人而异,本特性也不应该是破坏性,不明白阁下为什么执着于 Chrome 中输入 baidu.com
这一个场景。
你這不明明才輸入b就已經補全baidu.com了嗎?所以你到底在抱怨甚麼?
https://github.com/rime/librime/issues/686#issuecomment-1706591883 举 Chrome 中网址输入的例子的初衷是为了在一个普遍的场景下方便复现,以及论证该现象的存在性,而在 VSCode 协同 LaTeX 中文写作的场景下该现象还会更加普遍。
如果阁下对Chrome 地址栏输入网址的实验场景不满意,一定需要一个 VSCode 协同 LaTeX 中文写作的生产场景,本人当然可以提供,只是部署上述环境远比 Chrome 地址栏输入网址的环境复杂。
主鍵盤區敲兩個字母鍵的...
前文(#686 (comment), #686 (comment) ,#686 (comment) )已大段阐述使用修饰健直接输入拉丁字母的动机以及背景,此处不再赘述。输入习惯本来就因人而异,本特性也不应该是破坏性,不明白阁下为什么执着于 Chrome 中输入
baidu.com
这一个场景。你這不明明才輸入b就已經補全baidu.com了嗎?所以你到底在抱怨甚麼?
#686 (comment) 举 Chrome 中网址输入的例子的初衷是为了在一个普遍的场景下方便复现,以及论证该现象的存在性,而在 VSCode 协同 LaTeX 中文写作的场景下该现象还会更加普遍。
如果阁下对Chrome 地址栏输入网址的实验场景不满意,一定需要一个 VSCode 协同 LaTeX 中文写作的生产场景,本人当然可以提供,只是部署上述环境远比 Chrome 地址栏输入网址的环境复杂。
recognizer/patterns
新增一個latex命令的pattern(比如^\\[a-z]+$
)或者切換inline ascii mode
就能解決的事情……
https://github.com/rime/librime/assets/32028289/54772844-7b11-4de0-b119-18cef74bdf9e
请教如何设置带默认参数的 recognizer/patterns
以及 tab
定位下一个输入点,需要所有指令都设置一遍么?
大家好,当前本人已通过第三方开源 / 公共领域 (public domain) 软件 Karabiner 曲线实现了在中文环境下以组合键 ⌥ + [a-z]
直接上屏拉丁字母的功能。配置文件开源供后续有此需求的用户使用:
https://github.com/huangyxi/mac-keybindings/blob/main/karabiner/zh_latin.json
基于后附的实现原理和实际体验,虽然这样能够实现前面提及的功能,但是实现方法还是较为粗糙,输入法候选框还是会出现如闪一下的这类视觉干扰。如果条件允许的话还是希望能够将该功能内建。
⌥ + x
的组合键:是 -> 3,否 -> 中止x
实现背景
当前
key_binder/bindings
下设的功能有send
输出按键、toggle
切换开关选项、send_sequence
输出一串按键、set_option
设置开关选项、unset_option
取消设置开关选项、select
选择候选项,没有能直接输出字符的选项。 例如在 Mac 鼠须管前端中无论将快捷键Alt+a
配置为a
的send
功能 还是send_sequence
功能,输出的均为带有 accent 的字符å
。特性说明
希望增加一个功能,例如在
key_binder/bindings
下设一个commit
功能,使得通过组合健能直接将字符上屏,而不是模拟按键的输出,例如使用⌥/alt + a
直接上屏小写字母a
,或者其他任意字符。应用场景
在 VSCode 等 IDE、Chrome 地址栏等场景,有时需要通过直接输入英文字符来获得函数/网页地址的提示。如果以候选(暂不清楚如何称呼,即输入英文时的下划线的部分)方式输入在直接以
ascii_composer/switch_key
的commit_code
模式上屏有两个问题:其一是如果输入的英文字符串中被输入法以空格分词,则commit_code
上屏会造成 IDE / 浏览器的提示行为不同;其二是切换为西文后,如果再切回中文需要多按一次按键,打断输入过程。