关于Ctrl+Space，小狼毫应保持与系统一致的行为模式

[oTnTh]

我搜了一下，Ctrl+Space的问题在本项目曾经被提出过好几次，不过提交者都没有把该问题说得很明白，所以我想再尝试说明一下这个问题。

过去的Windows中，输入法设置是上图这个样子。

“默认输入语言”是“简体中文 - 美式键盘”，Ctrl+Space可以实现“美式键盘”跟“中文（简体） - 谷歌拼音输入法”之间的切换。

而在Windows 11中，输入法的行为模式已经发生了变化。

“简体中文 - 美式键盘”不再存在，按照上图的设置，开机后“微软拼音”就会默认开启。

如果想要开机默认是可以输入英文的模式，需要在“微软拼音”输入法中进行设置。

最重要的，也是小狼毫与系统行为模式不一致的地方。

Ctrl+Space在Windows 11中的功能，是用于“中/英文模式切换”，类似于小狼毫中的切换ascii_mode，而非过去那样“开启/关闭输入法”。

目前小狼毫的行为模式，会导致一直以来都存在，并且在其他主流输入法中依然可以使用的操作习惯出现问题：

1. 开机时默认为英文输入模式。
2. 按Ctrl+Space，开始输入中文，再按Ctrl+Space切换回英文输入模式。
3. 再次按Ctrl+Space，可以输入中文。

简单来说，就是默认输入英文，并且Ctrl+Space用作中文/英文的切换快捷键。

然而该操作流程，目前在小狼毫中是无法实现的。

这个问题之所以时不时有人提出，但又没有影响所有人，是不同的使用习惯导致的。

1. 大部分情况下都输入中文的人，ascii_mode设置为false，默认就是中文输入，Ctrl+Space可以实现中英文输入切换。
2. 习惯于用其他快捷键，例如shift切换中英文输入模式的人，也不受该问题的影响。

虽然这个问题说到底，还是Windows修改了输入法的行为模式导致的，不过我还是认为维护用户的使用习惯是很重要的。

写得有点长，图也很多，没找到法子能排版得更友好一点，非常感谢看到这里的人，谢谢。

[fxliang]

提供一点线索，供参考、思考
1.系统行为，还是微软拼音或微软五笔，或者其他什么输入法的行为？
2.高级键盘设置里面输入语言热键的这个Ctrl+Space是系统行为还是哪个应用的行为？

3.Rime用户，都只有一个方案？
4.每个方案，一定有ascii mode?
5.每个用户都要想初始化为ascii mode?
6.小狼毫TSF输入法的前后端分离的架构，如何让前端应用知道当前用的是什么方案？要初始化成ascii mode还是什么都不做？前端如何知道当前方案有没有ascii mode?
7.当前状态，方案可以初始化为ascii mode吗？已知的信息是可以的。
8.小狼毫可以实现Ctrl+Space切换ascii mode吗？从代码上只要增加一个按键绑定占用Ctrl+Space来执行一个新加的switch ascii mode的功能就有机会可以实现，那么这个时候的问题就会回到3,4,5,6的思考上
9.会有用户需要输入法/非输入法切换（开启/关闭键盘）这个现行的状态吗？
10.假如上面的这些问题有一个解，那么，收益是什么代价是什么值得投入吗？
11.以上这些问题，有一个合适的解决方案吗？pr welcome~

[lotem]

我在剛開始用 Windows 10 的時候嘗試過一種做法，包含以下幾個步驟：

1. 在操作系統設置中禁用 Ctrl+space 快捷鍵；
2. 在 Rime 配置中將 Control+space 快捷鍵設置爲切換 ascii_mode (code)

這種方式可以始終將小狼毫選定爲當前輸入法，並支持用 Control+space 切換中西文模式。
然而，這一方法的問題有：

1. 在步驟 1. 系統設置無法保存，通常在重啓電腦後復位爲啓用 Ctrl+space 的默認動作，從而導致 Rime 無法接收到。
2. 我在問答網站找到了解法，需要通過修改註冊表禁用 Ctrl+space 快捷鍵，重啓電腦後依然有效。然而長時間使用中，這個系統選項還是偶爾會復位。

我認爲「關閉鍵盤」這個狀態按照微軟拼音的演進來看，應該是過時了；如果不計較「懂輸入法」的特殊軟件，普通用戶用 ascii_mode 能得到相同的結果。

更好的解法，有可能要在輸入法前端代碼裏管住，不讓系統切換。似乎有人在本站提到過可以這樣做。

[fxliang]

更好的解法，有可能要在輸入法前端代碼裏管住，不讓系統切換。似乎有人在本站提到過可以這樣做。

就是要给小狼毫注册一个保留按键Ctrl+Space盖了系统的了，但是这样如果有人修改了这个还是会有机会有问题的。或者如果一旦发现键盘关闭了就重新打开，发送一次switch ascii mode

[lotem]

不是註冊快捷鍵。我記得有人說系統要關閉鍵盤時會給輸入法一個消息。輸入法可以管住，不管，系統就按默認的來。這得翻翻過往的相關討論。

[fxliang]

浅试过GUID_COMPARTMENT_KEYBOARD_OPENCLOSE消息收到的时候试去_SetKeyboardOpen(TRUE)会failed

[oTnTh]

提供一点线索，供参考、思考

@fxliang

我没有你那么了解rime和weasel，所以你提出的这些问题，我不一定都能正确理解你的意思，不过我会尽可能说清楚我的观点。

概括的说，我认为weasel应该为用户提供以下的功能：

1. 将weasel设置为默认输入法时，默认开启“英文输入模式”。
2. Ctrl+Space用于切换“中文输入模式”和“英文输入模式”。

我之所以用了“系统行为”这个词，是因为不管哪个版本的Windows，在使用内置输入法的时候，都可以实现这样的工作流程。如果你觉得“系统行为”这个说法有点模糊，那么只说“用户习惯”或“工作流程”其实也可以。

当然，并不每个用户都想要默认为英文输入模式，并且还喜欢用Ctrl+Space切换输入状态。但是这个工作流程长期以来都存在，当前版本的Windows，以及其他第三方输入法，都可以保留这样的使用习惯。而且说起来，Windows 7及以前的时候，这个才是默认的工作流程。所以我认为weasel应该提供这样的功能。

上图中确实写着“输入法/非输入法切换”，不过我认为这个应该是历史遗留问题了。该窗口以及相关的文本翻译存在的时间非常久了，Ctrl+Space的实际用途在Windows 11中确实发生了变化。

[oTnTh]

插几句可能有点跑题的猜测，微软之所以做出让输入法自己处理Ctrl+Space这样的修改，其实就是为了解放这一组快捷键。

西方国家不需要输入法，所以很多IDE中，Ctrl+Space是“自动完成”这一功能的快捷键。这对于又要写代码又要写中文的人来说就非常难受了，而程序员在这个问题上的发言权又比较大，所以在Windows 10中才做了这样的修改。

依稀记得Windows 10刚发布的时候，第三方输入法都不能用Ctrl+Space切换中英文输入模式，也是后来才都适配上这个特性的。

微软拼音中，只要“中/英文模式切换”中不勾选Ctrl+Space，VSCode等IDE中，都可以用这一组快捷键触发自动完成的功能。

看起来在Windows 11中，至少在内置输入法中，并不存在“关闭输入法”这个状态。Ctrl+Space也不是一个系统级的快捷键，如果输入法不捕获这一组快捷键的话，编辑器可以收到相关消息并进行处理。

[fxliang]

不是提问，只是列一下曾经思考这个问题未发现解法的过程有考虑的事情。

[mirtlebot]

那这个不是和系统保持一致了，是和微软拼音输入法等保持一致。

系统仍然将 Ctrl + Space 视作一个开启、关闭输入法的快捷键，微软拼音输入法可能覆写了。

Update:

我看有的配置方案连 ascii mode 的 processor 都没加，好像在 mac 上也正常用。

假如能实现的话，这样听起来可以

• 有这个 processor 并且 weasel.yaml:/good_ascii_mode: true 时，就接管这个快捷键；
• weasel.yaml:/good_ascii_mode: true 时，不接管快捷键。
• 没这个 processor，关闭键盘

默认就还是关闭键盘好了，感觉没啥影响。

[terrytw]

@oTnTh 有一点提示一下, "简体中文 - 美式键盘"是可以装回来的, 请你安装English - US语言包, 就会发现有ENG输入法了

此外这个界面并非翻译问题, 你可以看一下英文的说明和中文是相同的

我觉得很有意思的一点是, windows自己会提示说

实际上如果安装了rime, 微软拼音, ENG三种输入法的话, windows键+space会在三种输入法之间切换, 但是alt+shift会在上一次使用的中文输入法和ENG之间切换

如果微软拼音里把这个勾去掉的话

ctrl + space其实是无作用的, 所以@mirtlebot 说的"系统仍然将 Ctrl + Space 视作一个开启、关闭输入法的快捷键，微软拼音输入法可能覆写了。"这个我其实觉得非常符合逻辑, 但是和实际情况又不符

总而言之我觉得很难说清楚windows的intention是啥, 感觉微软自己都没想清楚, spaghetti code!

[fxliang]

这个我其实觉得非常符合逻辑, 但是和实际情况又不符

保留按键的设置是在tsf初始化的时候引入的，猜想可能是微软拼音其实那三个按键都初始化了保留按键，勾选只是改变了这些保留按键是否执行设定的中英文切换动作。如果我猜想的情况是真的，那就会出现ctrl+space既没有开关键盘也没有切换中英文的状态，这样就解释得通了。

至于微软多个快捷键的输入定义逻辑潜在可能有意图不明确的问题，猜想是因为输入法是分开不同团队做的，保留按键没有作为需求输入，于是各干各的就容易出现组合之后意图不明确的情况了。

[oTnTh]

@terrytw

"ime/Noime Toggle"和“输入法/非输入法切换”，这两句话，以及起所在的窗口，已经存在非常久了，至少Windows 8之前就在。在那个时候，Ctrl+Space确实是用来开关输入法的。

但是Windows 11的微软拼音中，Ctrl+Space是用来切换中英文输入模式的。行为模式确实出现了变化，但是上面那个窗口及其内容和翻译都没有发生变化，所以我才说这个是“历史遗留问题”。

在“语言和区域”中添加“英语（美国）”之后，实际上是添加了另外一种语言：

1、win+tab会弹出窗口，在rime、微软拼音和eng之间切换；
2、ctrl+shift只会在rime和微软拼音之间切换，也就是同一语言中的不同输入法/layout之间切换；
3、alt+shift会在“上一中文输入法”和eng之间切换，也就是不同“语言”之间切换。

---

看起来“系统行为”这个词还是引发了一点争议，不过我的本意重点其实不在这里。

1、默认为英文输入模式。
2、CTRL+Space可以切换中英文输入模式。

这个使用习惯长期以来都存在，并且现在在其他绝大部分主流输入法内依然可以实现，但是小狼毫不行。

诚然，解决办法是有的，shift也好，安装eng然后win+tab切也好，但这些法子其实都是让用户去改变使用习惯。如果没有非常必要且充足的理由，我觉得还是不要这样做比较好。

[wordpure]

Ctrl + Space 只是 输入法/非输入法切换（假设是这个名称） 这个系统 API 的一种调用方式，即使通过修改 Rime 配置将这个快捷键的功能改成中英文切换，其他应用调用这个 API 的时候，小狼毫还是会禁用输入法。

例如，Quicker 有个切换输入法状态的动作模块，其中的 切换为英文，在微软拼音、搜狗拼音中使用，都是将输入法切换为英文状态，但在小狼毫里使用，就是禁用输入法。

能否加一个设置项，让用户选择 输入法/非输入法切换 这个系统 API 对应的 rime 操作是切换中英文，还是切换输入法启用状态？

[hlc1209]

关闭输入法也好，ascii_mode也罢，都是好用与更好用的区别
但是拜托🙏先把恶性bug修复吧，已经到了极度影响日常使用的状态了。
是能用与不能用的区别
#1336

[yjnu]

我也用 Ctrl + 空格，中英切换，很好解决，AHK 写个快捷键就搞定了。

[kerwincsc]

调整注册表, 把 ctrl+space 开关输入法的功能给关了, 谁也不准用完事

[lotem]

是不是只要關閉二樓所示系統設置裏那個快捷鍵就行了？

rime 支持自定義快捷鍵。只要系統不禁用輸入法，rime 就能處理這個快捷鍵，用來切換內部的狀態。

根據我的總結，rime 的配置文件只能控制 rime 在接收到 Control+space 之後切換自身狀態，但管不到系統的快捷鍵。系統快捷鍵會優先執行，先把輸入法禁用了，因此 rime 就收不到了。

所以，系統的語言設置那裏禁用輸入法的快捷鍵也要一併改，給小狼毫設置 Control+space 的快捷鍵才能生效。

[oTnTh]

是不是只要關閉二樓所示系統設置裏那個快捷鍵就行了？

rime 支持自定義快捷鍵。只要系統不禁用輸入法，rime 就能處理這個快捷鍵，用來切換內部的狀態。

根據我的總結，rime 的配置文件只能控制 rime 在接收到 Control+space 之後切換自身狀態，但管不到系統的快捷鍵。系統快捷鍵會優先執行，先把輸入法禁用了，因此 rime 就收不到了。

所以，系統的語言設置那裏禁用輸入法的快捷鍵也要一併改，給小狼毫設置 Control+space 的快捷鍵才能生效。

这里有一个基于旧版小狼毫做的修改版，可以使用ctrl+space切换ascii模式： 4e20ebf

虽然我不是很懂，不过我猜应该是系统捕获ctrl+space被按下后，就向”当前输入法“发送了一个特定的消息，由输入法来决定要怎么处理。操作系统应该不会直接进行”关闭输入法“的操作，至少Win10以后应该是这样的。

至于AHK脚本之类的，即便默认该脚本绝对不会崩溃，也需要额外的手段解决如何往特权窗口发送消息的问题。作为一个临时方案或许可以，但其实并没有根本解决问题。

[lotem]

这里有一个基于旧版小狼毫做的修改版，可以使用ctrl+space切换ascii模式： 4e20ebf

@fxliang 有空研究研究。

[fxliang]

#1364 有基本实现这个了，待测试确认, #997 中的Windows11中浏览器的事项也要有人确认情况，不确定目前PR是否有影响那个issue的修复相关事项。@oTnTh

这个PR的逻辑是默认开关键盘的消息处理成切换ascii_mode，如果有需要保持原有逻辑的，可以运行WeaselSetup.exe /toggleime来恢复旧逻辑，WeaselSetup.exe /toggleascii 来重新切换回这个新的默认逻辑。

[oTnTh]

@fxliang 好的，非常感谢。等nightly build出来以后，我去测试一下。

[fxliang]

@fxliang 好的，非常感谢。等nightly build出来以后，我去测试一下。

先试下ci产出吧，合并了再报问题又得折回去，麻烦

[mirtlebot]

我在虚拟机 Win11 测试了下：

1. CI 版本确实变更为 ascii mode 切换而非开启/关闭键盘
2. 不影响网页快捷键 @fxliang
3. 如果一个方案没有 ascii mode，比如这种 https://github.com/LufsX/rime，按下系统快捷键，CI 版本将切换为一种特殊的状态，无任何候选，所有编码都进入 composition 栏的状态，按空格上屏。

希望跟随 rime 配置，禁用 ascii 切换功能。

[fxliang]

4.每个方案，一定有ascii mode?

看来我原来担心的是真实存在的🐶

[oTnTh]

CI版本我装上了，初看来ctrl+space确实可以切换ascii模式了。至于其他，用一用再来汇报情况。

[yjnu]

CI版本我装上了，初看来ctrl+space确实可以切换ascii模式了。至于其他，用一用再来汇报情况。

在中文模式，已有输入但未上屏字符，切换英文是不是会清掉？

[mirtlebot]

c380242#diff-ca01fbb0ebc4d8472b6965db870e611e61f5258dfbec52aaabf4fb2ab31124a0R256-R262

我反倒惊讶，原来 Weasel 切 ascii 模式，完全不需要配置里面有 ascii_composer。

不知道 Weasel 能不能知道用户当前配置有没有这项呢？

另外，像那个配置一样，即使没有 ascii_composer，macOS Squirrel 也是一样能变成英文输入，不知道是不是类似于原本的那种关闭了键盘，还是说 Squirrel 也是类似于 fcitx5-rime 那样是某个框架下面的一个东西。

[oTnTh]

在中文模式，已有输入但未上屏字符，切换英文是不是会清掉？

看一下ascii_composer，可以设置如何处理未上屏的内容，应该是你要找的东西。

[yjnu]

在中文模式，已有输入但未上屏字符，切换英文是不是会清掉？

看一下ascii_composer，可以设置如何处理未上屏的内容，应该是你要找的东西。

我知道啊，我是想问你 ctrl + space 切换是走的 ascii_composser 还是 key_binder。ctrl + space 中切英，会不会 commit_code

[oTnTh]

我知道啊，我是想问你 ctrl + space 切换是走的 ascii_composser 还是 key_binder。ctrl + space 中切英，会不会 commit_code

明白你的意思了，然后还测试出个bug来。

光标原本在“测试”两个字中间，敲“ceshi”之后直接按ctrl+space，状况如图。

既没有clear，也没有commit_code。按左右方向键，光标还可以在下划线区域内移动。按esc键以后，下划线区域消失。

[yjnu]

我知道啊，我是想问你 ctrl + space 切换是走的 ascii_composser 还是 key_binder。ctrl + space 中切英，会不会 commit_code

明白你的意思了，然后还测试出个bug来。

光标原本在“测试”两个字中间，敲“ceshi”之后直接按ctrl+space，状况如图。

既没有clear，也没有commit_code。按左右方向键，光标还可以在下划线区域内移动。按esc键以后，下划线区域消失。

可能切成 inline_ascii 模式了，这个状态下，你按回车可能就输入成功了

[fxliang]

提交或者清都不是问题，没有ascii_mode的方案才麻烦

[fxliang]

不知道 Weasel 能不能知道用户当前配置有没有这项呢？

@mirtlebot 印象中librime没有接口可以直接判断方案有没有某个option，而且那个是在服务端，到应用这里还有IPC。原来小狼毫的逻辑应该是默认都有ascii_composer的，所以状态里面固化了有ascii_mode, half/full这些

[fxliang]

如果一个方案没有 ascii mode，比如这种 https://github.com/LufsX/rime，按下系统快捷键，CI 版本将切换为一种特殊的状态，无任何候选，所有编码都进入 composition 栏的状态，按空格上屏。

这个应该是因为，没有ascii_composer,但是却留下了ascii_segmentor，于是就这样了@mirtlebot

[oTnTh]

我去看了一下前面提到的，没有ascii_composer的方案： https://github.com/LufsX/rime/blob/master/lufs_pinyin.schema.yaml

看原作者的意思，不同的平台也是需要不同的配置的。

engine:
  processors:
    # - ascii_composer # Windows 用户请解除此行注释，否则将会无法切换到英文输入
    - recognizer
    - lua_processor@select_character # lua 选词扩展，如需关闭请注释
    - key_binder
    - speller
    - selector
    - punctuator
    - navigator
    - express_editor

[fxliang]

新加两行，切换ascii后清空composition

[mirtlebot]

感谢你的 PR 和回复。

似乎这个问题并非此 PR 需要解决的问题，牵扯的东西应当不只这个议题。

比如，我刚刚翻看了之前使用命令参数修改 ascii mode 的 PR，https://github.com/rime/weasel/pull/1113/files 。应当同样是没有对无 ascii mode 的配置做调整。

此外，这个问题影响很小，很少有配置这么写。即使有，暂时要求配置添加对应 processor 即可。

看一看有没有其他副作用，大概就可以合并入主分支了。

[mirtlebot]

印象中librime没有接口可以直接判断方案有没有某个option

Option 似乎并不重要，如那个方案，有 Option，但完全无作用，只要看 engine（processor 和 segmentors）即可。而 librime-lua 提供了获取方案 engine 的 lua API，因此 librime 应当有对应的 API。

至于判断起来方不方便就在我能力之外了。如上评论，感觉这种情况不需要在这个 PR 中解决。

[j1g5awi]

4.每个方案，一定有ascii mode?

关于这点，我的方案还使用 lua hack 了 ascii mode，而用 ctrl+space 是希望回到正常的 qwertry 键盘。

我赞同将与系统不一致的行为视作 bug 修复，但更改默认行为的更新是否该更慎重一点？今天更新后对 ctrl+space 切换 ascii 的行为摸不着头脑，最后找到本 Issue。

[hzinchengdu]

4.每个方案，一定有ascii mode?

关于这点，我的方案还使用 lua hack 了 ascii mode，而用 ctrl+space 是希望回到正常的 qwertry 键盘。

我赞同将与系统不一致的行为视作 bug 修复，但更改默认行为的更新是否该更慎重一点？今天更新后对 ctrl+space 切换 ascii 的行为摸不着头脑，最后找到本 Issue。

更新后的版本用Ctrl+Space不能切换时上屏原始的编码，请问怎么配置。

[oTnTh]

更新后的版本用Ctrl+Space不能切换时上屏原始的编码，请问怎么配置。

好像并不能配置

[yjnu]

更新后的版本用Ctrl+Space不能切换时上屏原始的编码，请问怎么配置。

好像并不能配置

@fxliang 大佬关于这个问题，后面会继续更改，还是保持现状

[hzinchengdu]

更新后的版本用Ctrl+Space不能切换时上屏原始的编码，请问怎么配置。

好像并不能配置

想知道你是怎么用lua hack的，最新版本能否用lua方式实现Ctrl+space上屏编码