我启用了xterm-keys在 tmux 中启用了正常的 xterm 键绑定，例如使用Ctrl-箭头键。
然而，启用xterm-keys它会导致Shift-Enter产生不良影响vim。特别是，Shift-Enter在正常模式下按 会切换从光标位置开始的 13 个字母的大小写，而不考虑单词边界。在命令模式下按按键可退出该模式，然后切换 13 个字母的大小写。通常在 中vim，按此键的结果是向下移动一行（正常模式）或执行任何输入的命令（命令模式），据我所知，这些是默认行为。
我已经用空.tmux.conf和.vimrc文件重现了这种效果，因此它不是其他配置设置的副作用。
答案1
您现在正在使用该F14½密钥。
你已经误入了世界哈利·波特，其中DEC VT 键盘上的和键之间有一个F14½键。 VIM 并不熟悉这个世界。F14Help
在 DEC VT 键盘上，如图中的 LK401（对于 DEC VT420），用于生成编号为 11 到 34 的输入控制序列 (DECFNK) 的功能键。F1额外F20的 DECFNK 编号对应于键盘上的物理间隙，其中实际上不是钥匙。一旦人们意识到这一点，这是非常合乎逻辑的。 （进一步阅读中有更多内容。）特别是，F14生成 DECFNK 26 控制序列并Help生成 DECFNK 28 控制序列。
如果在 XTerm 中打开该modifyOtherkeys选项，则当按下修饰符时，XTerm 不会为一大堆键盘按键生成更常见的输入控制序列，而是在 DECFNK 27 上生成一大堆变体，即F14和之间的间隙代码Help。其背后的想法是，TUI 程序可以区分这些键的各种修改和未修改的用途，而它通常无法做到这一点。
该Enter键通常会生成 ␍ 作为输入，但在通过 修改时生成 ␊ 时除外⎈ Control，在此模式下，当与 结合使用时，会生成 DECFNK 27;2;13⇧ Shift，在此模式下，当与和其他 DECFNK 27;中号;13 个修饰符其他组合的序列。
tmux 中的选项xterm-keys使 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 个字符的大小写。