通过组合键使英文小写直接上屏

[huangyxi]

实现背景

当前 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 / 浏览器的提示行为不同；其二是切换为西文后，如果再切回中文需要多按一次按键，打断输入过程。

[groverlynn]

例如在 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

[huangyxi]

{ when: composing, accept: Alt+a, send_sequence: "a{Return}" }
感谢回复。但是测试了一下，Mao 鼠须管中无论是when: composing还是when: always仍然无法在输入⌥ + a的情况下直接上屏a。

[lotem]

如果說，按組合鍵，上屏指定的任意Unicode字符串，我覺得這個功能有意義，是現有機制不容易做到的。

單說要用快捷鍵直接上屏英文小写，不太理解使用的場景。總感覺不是最好的實現方法。

[lotem]

又仔細讀了一遍原題中的背景介紹。
要說錄入單個字母取得提示，發個組合鍵是挺快。但這裏有兩個破綻：
一是有的自動補全提示場景，需要繼續輸入多個字母才能定位到想要的選項，那麼連續發快捷鍵就不像單發那樣操作便捷了。
二是發組合鍵要事先想到這個場景要讓字母上屏，先在顱內切換好輸入方式，再指揮雙手做出一套與平時輸入字母不同的動作，心智負擔蠻大。

會不會有更自然，同樣快速，且適應更多場景的操作方式呢。

我看，輸入字母序列後按一個表示字母原樣上屏的功能鍵就不錯，比如很多方案裏配置的 Return 或是 Shift+Return。字母較多時依舊操作便捷，沒有提前想到切換也能在輸入字母後補救，他最大的好處是不改變已經習慣的字母輸入方式，無需任何適應性訓練。其侷限僅僅是和一些形碼的自動上屏功能有衝突。

[huangyxi]

感谢开发者有耐心从用户的场景理解需求。

对于本人之前的背景描述，开发者给出了 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 也有同样的烦恼。

[groverlynn]

{ when: composing, accept: Alt+a, send_sequence: "a{Return}" }
感谢回复。但是测试了一下，Mao 鼠须管中无论是when: composing还是when: always仍然无法在输入⌥ + a的情况下直接上屏a。

Screen.Recording.2023-08-24.at.19.22.14.mov

當且僅當⌥ + a爲dead key時快捷鍵無效，因爲系統仍在等待用戶輸入被dead key修飾的鍵

[groverlynn]

感谢开发者有耐心从用户的场景理解需求。

对于本人之前的背景描述，开发者给出了 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），多半網址就直接補全了。這樣不更符合輸入邏輯嗎？

[huangyxi]

按照 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%。

[groverlynn]

按照 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%。

Screen.Recording.2023-09-04.at.03.45.58.mov

[huangyxi]

Screen.Recording.2023-09-04.at.09.55.13.mov

[groverlynn]

Screen.Recording.2023-09-04.at.09.55.13.mov

應該是你用baidu.com完整URL的次數還不夠，搜索的優先級比較高

[huangyxi]

應該是你用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 中文写作的场景下该现象还会更加普遍。

[groverlynn]

應該是你用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 中文写作的场景下该现象还会更加普遍。

Screen.Recording.2023-09-05.at.16.52.12.mov

完全無法複現你所提到的情況。才輸入五六次就已經首字母直接補全網址了。回車上屏已輸入的網址且不切換ASCII，再回車打開網站。比什麼組合鍵輸入小寫要方便得多吧？何況網址不區分大小寫，你也完全可以capslock

[huangyxi]

请问阁下输5、6次之前有出现过没有补全网址的情况么？

[huangyxi]

回車上屏已輸入的網址且不切換ASCII，再回車打開網站。比什麼組合鍵輸入小寫要方便得多吧？

请详见数学分析 #686 (comment) 。

[groverlynn]

请问阁下输5、6次之前有出现过没有补全网址的情况么？

當然有啊，chrome的設計就是這樣的啊，是否補全網址取決於近期是否高頻登入該網址

[groverlynn]

回車上屏已輸入的網址且不切換ASCII，再回車打開網站。比什麼組合鍵輸入小寫要方便得多吧？

请详见数学分析 #686 (comment) 。

然而直接回車並非切換ascii模式，此時 $$\eta(c)=\frac{c}{c+1}$$ 理論上和你提出的組合鍵輸入效率相同，實際上因爲不破壞輸入的手型，效率是高於你的組合鍵方案的

P.S.修飾鍵與主鍵並非同時按下，而是先按修飾鍵然後在未抬起修飾鍵的情況下按下主鍵。平均耗時必定超過按兩個字母鍵（按鍵位置越偏遠耗時越久；加上組合鍵按下的時間必須重疊的要求，導致絕大多數情況下都是先抬起主鍵，後抬起修飾鍵，所以即便不考慮修飾鍵的偏遠位置和對輸入手型的破壞，耗時都應該至少是按兩鍵）。

[huangyxi]

平均耗時必定超過按兩個字母鍵（按鍵位置越偏遠耗時越久；

实际上本人使用 shift 输入大写拉丁字母的效率几乎等同于输入输入小写拉丁字母的效率。即便左手小拇指(little finger)按下 shift 的同时无名指(ring finger)敲击其他字母的时间也仅仅略长于仅敲击小写拉丁字母（约0.2x），右手敲击右手区大写拉丁字母的时间更是接近直接敲击小写拉丁字母。

然而直接回車並非切換ascii模式，此時...
...按鍵位置越偏遠耗時越久...

在 QWERTY 布局中，比起右手默认键位 ; 与 return 的距离，左手默认指位 A 与左 shift 的距离要更加接近，耗时也必定越少。

[groverlynn]

平均耗時必定超過按兩個字母鍵（按鍵位置越偏遠耗時越久；

实际上本人使用 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了嗎？所以你到底在抱怨甚麼？

[huangyxi]

主鍵盤區敲兩個字母鍵的...

前文（#686 (comment), #686 (comment) ,#686 (comment) ）已大段阐述使用修饰健直接输入拉丁字母的动机以及背景，此处不再赘述。输入习惯本来就因人而异，本特性也不应该是破坏性，不明白阁下为什么执着于 Chrome 中输入 baidu.com 这一个场景。

你這不明明才輸入b就已經補全baidu.com了嗎？所以你到底在抱怨甚麼？

#686 (comment) 举 Chrome 中网址输入的例子的初衷是为了在一个普遍的场景下方便复现，以及论证该现象的存在性，而在 VSCode 协同 LaTeX 中文写作的场景下该现象还会更加普遍。

如果阁下对Chrome 地址栏输入网址的实验场景不满意，一定需要一个 VSCode 协同 LaTeX 中文写作的生产场景，本人当然可以提供，只是部署上述环境远比 Chrome 地址栏输入网址的环境复杂。

[groverlynn]

主鍵盤區敲兩個字母鍵的...

前文（#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就能解決的事情……

[huangyxi]

Screen.Recording.2023-09-18.at.23.20.28.mov

请教如何设置带默认参数的 recognizer/patterns 以及 tab 定位下一个输入点，需要所有指令都设置一遍么？

[huangyxi]

大家好，当前本人已通过第三方开源 / 公共领域 (public domain) 软件 Karabiner 曲线实现了在中文环境下以组合键 ⌥ + [a-z] 直接上屏拉丁字母的功能。配置文件开源供后续有此需求的用户使用：
https://github.com/huangyxi/mac-keybindings/blob/main/karabiner/zh_latin.json

基于后附的实现原理和实际体验，虽然这样能够实现前面提及的功能，但是实现方法还是较为粗糙，输入法候选框还是会出现如闪一下的这类视觉干扰。如果条件允许的话还是希望能够将该功能内建。

实现原理

1. 判定是否是在中文输入法环境：是 -> 2，否 -> 中止
2. 判定是否按下如 ⌥ + x 的组合键：是 -> 3，否 -> 中止
3. 切换当前输入法为英文
4. 模拟按键输出如 x
5. 切换输入法回中文