☰

进一步阅读

tag-icon • tag-icon shell terminal tmux
进一步阅读

我已escape-time在 中设置了该选项~/.tmux.conf，因为它存在于许多 Tmux 配置文件中。

但是，设置此选项后我并没有真正看到任何效果。特别是，如果我将 设为escape-time10000（10 秒），一切仍然“有效”。

这是我当前的设置：

# ESC delay after prefix (ms)
set -sg escape-time 500

“ESC 延迟”到底是什么意思，什么时候使用？

答案1

终端只是向主机发送字符流。对于主键中的键字母数字部分键盘的（ISO 9995 术语）这很好，因为它们通常发送普通的可打印字符或 C0 控制字符。

当涉及键盘其他部分的光标键、功能键、编辑键等时，情况有所不同，即使在主要部分中没有明显控制字符关联的键和弦（例如⇧ Shift+⇥ Tab或+）用作⎇ Alt促进剂改性剂。

ECMA-35 和 ECMA-48 定义了一个系统转义序列，由 ESC 字符 (U+001B) 引入，以及控制序列，由 CSI 角色引入（U+009B，Control Sequence Introducer 的缩写）。终端主要采用后者；←例如，为密钥发送的 ECMA-48 CUB（CUrsor Backwards）控制序列。

如果不是终端（包括仿真终端）仍然存在于 20 世纪 70 年代，也就是世界基本上都在发展之前，这也将是一件好事。8位干净。

终端的行为就好像世界仍然广泛使用具有奇/偶/无奇偶校验的 7 位串行编码，这是 PC 革命、BBS 和 FidoNet 等人的成果。在 20 世纪 80 年代帮助挖坟墓，支持 8N1。所以他们使用7 位别名用于传输 C1 控制字符（例如 CSI）的格式。

此表格适用于7 位传输无法干净地传输8位字符。这意味着它们实际上将 C1 控制字符作为 ESC 字符传输，后跟 C1 字符代码减 64（ESC Fe对于那些读取 ECMA-35 的人）。这反过来意味着所有控制序列名义上以 C1 控制字符开头没有对应于键盘上的一个键，现在改为以 C0 控制字符开头，其中是键盘上的一个键。

您会看到，那些讨厌的用户有一个Esc键可以单独发送 ESC 字符，而不是作为转义序列的一部分。他们喜欢在 TUI 程序中使用它来表示“更改模式”或“取消操作”或其他含义。几年前，当苹果阻止它成为苹果键盘上真正的物理键时，他们有些抱怨。

那么什么是一个逐字符读取终端输入的应用程序，就像viand 之类的程序一样tmux（在其实现上）外终端），做什么？它如何区分拥有 ESC 键并乐意使用它的用户与通过 7 位传输发送控制序列的终端？

它设置了一个超时时间。如果 ESC 之后的字符到达得足够快，则可能这是一个发送 ECMA-48 控制序列的终端，它将以机器速度执行此操作。如果 ESC 之后的字符在最小延迟后到达，则可能这是一个人类Esc在输入其他内容之前先输入该键。

这就是escape-time设置的全部内容。 tmux让你配置超时（VIM 和 NeoVIM 也是如此），其他程序通常会硬连线。您将其设置为 10 秒只是告诉它机器可能非常慢，这通常是没有意义的。越多通常修改是为了减少它，因为你是一个可以快速打字的人。

如今，这个想法的主要问题是，在程序中引入 SSH 和网络传输延迟，可能会导致人为输入真的可以之所以能这么快到达，是因为它已经聚集在“本地”端，等待远程主机的确认以移动传输窗口。并且还引入了网络的可能性分手机器生成的控制序列，在 ESC 字符之后产生延迟，使远程主机上运行的程序错误地猜测它是人类键入的。

也许全世界都会明白 TCP 也是 8 位干净的（是的，官方的；自1981年以来），正如串行通信已有数十年历史一样，终端确实可以发送真正的 CSI 字符而不是其 7 位别名。这样，终端生成的控制序列和那些讨厌的用户单击按键之间的歧义就会减少（预留加速器）Esc，并且程序不需要测量接收字符之间的时间来知道它们是否正在处理机器或人。

毕竟，真实的终端明白了这样一个事实：世界在 20 世纪 80 年代……在 80 年代初实现了 8 位清洁。 DEC VT220 于 1983 年发布，S8C1T 控制序列它告诉终端停止使用 7 位别名并开始发送正确的 U+009B 字符。到 1987 年 VT320 出现时，这是一项存储在终端非易失性 RAM 中的设置功能，默认情况下可以打开。相同的设置工厂默认为 8N1。

进一步阅读

相关内容