在 `tmux` 中设置 `xterm-keys` 会影响 `vim` 中的 Shift-Enter

Question

在 `tmux` 中设置 `xterm-keys` 会影响 `vim` 中的 Shift-Enter

我xterm-keys在 tmux 中启用了正常的 xterm 键绑定，例如使用Ctrl 箭头键进行全字移动。

但是，通过启用xterm-keys它会导致Shift-Enter在vim. 特别是，Shift-Enter在正常模式下按下可切换从光标位置开始的 13 个字母的大写，而与单词边界无关。在命令模式下按这些键会退出该模式，然后切换 13 个字母的大写。通常在中vim，此按键的结果是向下移动一行（正常模式）或执行任何输入的命令（命令模式），据我所知，这些是默认行为。

我转载空这个效果.tmux.conf和.vimrc文件，所以它不是其他配置设置的副作用。

Answer 1

Jde*_*eBP 5

您现在正在使用`F14½`密钥。

您已经走进了哈利波特的世界，那里有一个 DEC VT 键盘上F14½的F14和Help键之间的键。VIM不熟悉这个世界。

LK401 键盘

在 DEC VT 键盘上，如图片中的 LK401（用于 DEC VT420），功能键F1用于F20生成编号为 11 到 34 的输入控制序列 (DECFNK)。额外的 DECFNK 编号对应于键盘上的物理间隙实际上不是钥匙。这十分合乎逻辑，一旦人们意识到这一点。（在进一步阅读中有更多关于此的内容。）特别是，F14生成一个 DECFNK 26 控制序列并Help生成一个 DECFNK 28 控制序列。

如果打开modifyOtherkeysXTerm 中的选项，而不是为一大堆键盘键生成更常用的输入控制序列，当按下修饰符时，XTerm 会在 DECFNK 27 上生成一大堆变体，即F14和Help. 这背后的想法是，TUI 程序可以区分这些密钥的各种修改和未修改用途，而这通常是无法做到的。

该Enter键通常生成 ␍ 作为输入，除了在被修改时生成 ␊ 时⎈ Control，在这种模式下，当⇧ Shift与其他 DECFNK 27; 和其他 DECFNK 27;组合使用时，生成 DECFNK 27;2;13 ; M ;13 其他修饰符组合的序列。

xterm-keystmux 中的选项让 tmux 了解这一切。它将这些控制序列识别为输入，并将它们作为输入发送到多路复用的终端。

问题是很少有 Unix 和 Linux 工具真正正确理解这些控制序列。为了正确处理终端输入，需要一个 ECMA-48 控制序列解析器，它知道中间字符、参数字符、最终字符等。但是使用 libedit、ZLE 和 Readline 等库的程序（包括 shell）；使用 ncurses 的程序；而像 VIM 这样的程序没有 ECMA-48 控制序列解析器。（同样，在进一步阅读中有更多关于此的内容。）它们没有正确处理实际的终端协议。

相反，他们拥有的是进行过于简单的模式匹配的临时输入处理程序。这意味着它们无法处理 XTerm 和 tmux 此处使用的形式的 DECFNK 序列。

DECFNK 27;2;13 完整拼写为字符序列 CSI 2 7 ; 2 ; 1 3 ~。使用来自 ECMA-48 的 7 位代码扩展使 ESC [ 2 7 ; 2 ; 1 3 ~. VIM 没有将其正确解码为 ECMA-48 控制序列，误解了终端输入，并且1 3 ~控制序列尾部的字符最终产生了您看到的效果，转换了 13 个字符的大写。

归档时间：	6 年，5 月前
查看次数：	555 次
最近记录：	6 年，5 月前

在 `tmux` 中设置 `xterm-keys` 会影响 `vim` 中的 Shift-Enter

您现在正在使用F14½密钥。

进一步阅读

您现在正在使用`F14½`密钥。