主页 / unix / 问题 / 520273
Accepted
user001
Asked: 2019-05-22 14:04:46 +0800 CST

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

  • 772

我在 tmux 中启用xterm-keys了正常的 xterm 键绑定，例如使用Ctrl 箭头键移动整个单词。

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

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

vim tmux

1 个回答

  1. Best Answer

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

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

    LK401键盘

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

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

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

    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 个字符的大写。

    进一步阅读

    • 5

相关问题