Ctrl+Shift+字母会折叠为 Ctrl+字母; xterm modifyOtherKeys(ESC[>4;2m) 将被忽略
作者: cattyhouse创建于 2026年9月20日更新于 2026年9月20日
- 症状
- 在 tmux 外部,
cat -v显示Ctrl+F和Ctrl+Shift+F都为^F。在printf '\e[>4;2m'后,仍然为^F^F。因此, xtermmodifyOtherKeys启用没有任何效果。 - 在 tmux 外部,使用 Kitty 键盘协议的应用程序(例如,
pi发送ESC[>7u) 可以正常工作:Ctrl+Shift+F到达ESC[102;6u。 - 在 tmux 内部,
Ctrl+Shift+F从未到达内部应用程序:在extended-keys on,extended-keys-format csi-u和terminal-features ",rio*:extkeys"设置下,pane_key_mode变为Ext 2,但cat -v在ESC[>4;2m后仍然显示^[[102;5u^[[102;5u(均为 Ctrl+F)。同一个 tmux 设置中的 Ghostty 显示^[[102;5u而不是^[[102;6u并正常工作。 - 实际影响:
pi记录搜索(ctrl+shift+f) 在 rio 外部 tmux 中和在ghostty+tmux中都可以正常工作,但在rio+tmux中却不能。
- 可能的原因
- Rio 似乎实现了 Kitty 键盘处理(
kitty_keyboard.rs),但忽略了 xtermmodifyOtherKeys启用/禁用序列(ESC[>4;1m,ESC[>4;2m,ESC[>4;0m)。 - tmux 只在外部终端中使用 xterm 模式 2 请求扩展键(
Eneks=\E[>4;2m,参见 tmux 3.5 变更: "始终从父终端请求模式 2");它从外部终端中从未发送 Kitty 推送(ESC[>...u)。它接受了外部终端发送的CSI 27 ~和CSI u。 - 因此, tmux 从来无法将 Rio 置于扩展模式: tmux 发送
>4;2m, Rio 忽略了它并继续发送传统的0x06,tmux 将其转发为Ctrl+F。Ghostty 之所以能正常工作,是因为它未经请求地发送了CSI-u。 - 建议:在 Rio 中支持 xterm
modifyOtherKeys启用序列(至少是>4;1m,>4;2m,>4;0m),或者文档说明 Rio 仅支持 Kitty,因此多路复用器如 tmux 无法通过 xterm 路径驱动它。
内容来源: raphamorim/rio