使用 tmux 或 screen 在 vi​​m 中切换模式时出现轻微延迟

Question

由于我使用了 tmux，因此在 Vim 中切换插入模式和从插入模式切换不再是即时的。Esc在插入模式下按下后，需要很长时间才能真正退出插入模式。按下Esc和之后的任何其他键后立即切换，并Esc执行之后按下的键的命令。知道什么可能导致这种情况吗？

Vim 配置不是问题，因为当我在 tmux 之外运行 Vim 时不会发生延迟，所以这可能与 tmux 有某种关系。顺便说一句，我使用 gnome-terminal。

同样值得注意的是，似乎我无法在 tmux for 中定义键绑定Esc，我的计划是绑定Esc到：

bind Escape send-keys ^[

唉，似乎Esc为 tmux绑定任何东西都不起作用。同样的问题也出现在屏幕上。

Answer 1

在翻阅手册页后，发现 tmux 有一个选项。以下内容~/.tmux.conf修复了延迟问题：

 set -sg escape-time 0

您必须重新启动 tmux 服务器或重新加载配置才能生效。为此，请source-file ~/.tmux.conf从 tmux 提示符发出。

Answer 2

当我找到这个页面时，我有一个不同但相似的问题，我试图解决这个问题，所以我会在这里发布它，以防它对其他正在寻找这个答案并以相同方式找到这个页面的人有帮助。

问题：bash 中的 vi 模式在从插入模式切换到命令模式时有延迟

解决方案：在您的~/.inputrc文件中，添加set keyseq-timeout nwheren是一些大于 0 的低值。 n默认为 500 毫秒，这就是导致延迟的原因。请参阅此处的文档。

此外，如果您想知道自己处于哪种模式，请查看Dylan Cali 的 bash 分支。

Answer 3

长话短说：

\n

不要使用escape-time 0，而是将其设置为一个较低的值。

\n

在~/.tmux.conf：

\n

set -s escape-time 50  # ~5-100. https://superuser.com/a/1809494/224906\n

\n

通过重新加载 tmux 配置或重新启动 tmux 服务器来完成。（在 CLI 中，运行 或tmux source-file ~/.tmux.conf。tmux kill-server; tmux）

\n

详细说明：

\n

在过去几个月里花了几天时间在远程连接到 tmux 服务器（通过 iTerm2 3.4.20 -> zsh 5.8.1 -> ssh 8.9p1 -> zsh 5.8.1 -> tmux 3.3a)，我强烈建议不要将escape-time 设置为 0 (正如这里其他人的建议，甚至是tmux-sensible 的建议，它在我发帖时链接到了这个问题)，而是将 escape-time 设置为较低的值，例如 10 或 50（默认为 500）。

\n

为什么？我终于在 GitHub 问题“tmux 3.3 Leaks text into shell”中找到了解决方案：

\n

\n

escape-time 0防止 tmux 识别跨读取/数据包边界分段的转义序列。您应该将其提高到一个更合理的值，例如 100 毫秒，这对于大多数情况来说应该是足够的时间，同时仍然足够快，不会导致人类规模的交互问题。

\n

\n

他使用的终端与我完全不同（wezterm vs iTerm2），但遇到了非常相似的组合 CSI（控制序列引入器）和 DCS（设备控制字符串）转义序列 \xe2\x80\x94 特别是 \ \\033[>0;95;0c\\033P>|iTerm2 3.4.20\\033\\\\xe2\x80 的问题\x94 响应 CSI 转义序列CSI > c（又名\\033 [ > c）和CSI > q（又名\\033 [ > q）泄漏到 shell 中。（至少对我来说，这似乎总是按顺序依次发生。）

\n

一段时间后，这会导致我的 vim 缓冲区中发生随机粘贴，然后将 Term2 3.4.20[sic] 添加到粘贴的文本前面。

\n

帮助其他人寻找此解决方案的更多详细信息：

\n

组合的 CSI 和 DCS 序列\\033[>0;95;0c\\033P>|iTerm2 3.4.20\\033\\\\在 vim 中导致以下结果：\\033[>0;95;0c\\033不做太多事情，P粘贴 vim 的未命名/默认寄存器中的任何内容，>|将行制表符向右，i进入插入模式，Term2 3.4.20插入到缓冲区中，\\033转义退出插入模式，最后的\\\\基本上什么也不做。

\n

我观察到，当我在路上时，尤其是在使用不可靠且缓慢的移动连接时，这种情况更常见。现在这是完全有道理的，因为在这些条件下数据包延迟会更大，而且因为我使用的是escape-time 0.

\n

TL;DR：不要使用escape-time 0; 它的存在是有充分理由的。为其指定一个较低的合理值（例如 5、50 或 100），该值在远程连接时仍能正常工作。根据需要进行调整以找到适当的平衡。如果该值太高，则会干扰人类规模的交互。如果该值太低，您可能会遇到转义序列伪影和错误。

\n

编辑： GitHub 上的 Microsoft WSL 问题中也引用了此问题和解决方案，它同样链接回这个问题。

\n

编辑＃2：我还了解到，我上面描述的问题可能（也许更有可能）是由于TTY_QUERY_TIMEOUT设置tmux/tty.c得不够高，但这超出了这个问题的范围。您确实不应该使用escape-time 0由于上述原因，

\n