Emacs、unicode、xterm 鼠标转义序列和宽终端

Question

简短版本：当使用 emacs 的 xterm-mouse-mode 时，有人（emacs？bash？xterm？）拦截 xterm 的控制序列并将其替换为 \0。这对于宽显示器来说是一个痛苦，因为只有前 223 列有鼠标。

罪魁祸首是什么？我该如何解决它？

据我所知，这与 Unicode/UTF-8 支持有关，因为 5-6 年前当我最后一次拥有大显示器时，这不是问题。

血淋淋的细节如下...

谢谢！

Emacs xterm-mouse-mode 在处理从 x=95 左右开始的鼠标单击时有一个众所周知的弱点。最新版本的 emacs 采用的一种解决方法解决了该问题到x=223。

几年前，我发现 xterm 以 7 位八位组的形式对位置进行编码。给定要编码的位置“x”，其中 X=x-96，发送：

\40+x (x < 96)  
\300+X/64 \200+X%64 (otherwise)  

我们必须向 emacs 中给定的 x 位置加一，因为 xterm 中的位置从 1 开始，而不是从 0 开始。因此，神奇的 x=95 数字就会弹出，因为它被编码为“\300\200”——第一个转义数字。有人（emacs？bash？xterm？）将它们视为ISO 2022中的“C0”控制序列。从 x=159 开始，我们更改为“C1”序列 (\301\200)，这也是 ISO 2022 的一部分。

\302 序列遇到问题，它对应于当前的 x=223 限制。几年前，我能够扩展 hack 来手动拦截 \302 和 \303 序列，这解决了这个问题。快进几年，今天我发现我被困在 x=223 处，因为有人用 \0 替换这些序列。

因此，我希望单击第 1 行第 250 行生成

ESC [ M SPC \303\207 ! ESC [ M # \303\207 !

Emacs 报告（对于任何第 223 列），

ESC [ M SPC C-@ ! ESC [ M # C-@ !

我怀疑 Unicode/UTF-8 支持是罪魁祸首。一些挖掘表明，直到 2000 年 11 月，Unicode 标准才允许 C0 和 C1 序列作为 UTF-8 的一部分 ，我猜有人没有收到备忘录（幸运的是）。但是，\302\200 - \302\237 是 Unicode 控制序列 ，所以有人把它们吞掉了（谁知道用它们做什么！）并返回 \0 。

一些更详细的问题：
- 在代码到达 emacs 的丢失缓冲区之前拦截代码的人是谁？
- 如果它真的只是关于控制序列，为什么 \302\237 之后的字符（可打印 Unicode 的 UTF-8 编码）也返回为 \0 ？
- 是什么让 emacs 决定是否将丢失显示为 unicode 字符或八进制转义序列，以及为什么两者不匹配？例如，我自建的 cygwin emacs 23.2.1 (xterm 229) 报告第 161 列为 \301\202，但我的 rhel5.5 提供的 emacs 22.3.1 (xterm 215) 报告“”（带有抑扬符的拉丁语 A） ，实际上是 UTF-8 中的 \303\202！

更新：

这是一个针对 xterm-261 的补丁，它可以以 utf-8 格式发出鼠标位置：

diff -r button.c button.utf-8-fix.c
--- a/button.c  Sat Aug 14 08:23:00 2010 +0200
+++ b/button.c  Thu Aug 26 16:16:48 2010 +0200
@@ -3994,1 +3994,27 @@
-#define MOUSE_LIMIT (255 - 32)
+#define MOUSE_LIMIT (2047 - 32)
+#define MOUSE_UTF_8_START (127 - 32)
+
+static unsigned
+EmitMousePosition(Char line[], unsigned count, int value)
+{
+    /* Add pointer position to key sequence
+     * 
+     * Encode large positions as two-byte UTF-8 
+     *
+     * NOTE: historically, it was possible to emit 256, which became
+     * zero by truncation to 8 bits. While this was arguably a bug,
+     * it's also somewhat useful as a past-end marker so we keep it.
+     */
+    if(value == MOUSE_LIMIT) {
+       line[count++] = CharOf(0);
+    }
+    else if(value < MOUSE_UTF_8_START) {
+       line[count++] = CharOf(' ' + value + 1);
+    }
+    else {
+       value += ' ' + 1;
+       line[count++] = CharOf(0xC0 + (value >> 6));
+       line[count++] = CharOf(0x80 + (value & 0x3F));
+    }
+    return count;
+}
@@ -4001,1 +4027,1 @@
-    Char line[6];
+    Char line[9]; /* \e [ > M Pb Pxh Pxl Pyh Pyl */
@@ -4021,2 +4047,0 @@
-    else if (row > MOUSE_LIMIT)
-       row = MOUSE_LIMIT;
@@ -4028,1 +4052,5 @@
-    else if (col > MOUSE_LIMIT)
+
+    /* Limit to representable mouse dimensions */
+    if (row > MOUSE_LIMIT)
+       row = MOUSE_LIMIT;
+    if (col > MOUSE_LIMIT)
@@ -4090,2 +4118,2 @@
-       line[count++] = CharOf(' ' + col + 1);
-       line[count++] = CharOf(' ' + row + 1);
+       count = EmitMousePosition(line, count, col);
+       count = EmitMousePosition(line, count, row);

希望这个（或类似的东西）会出现在 xterm 的未来版本中...该补丁使xterm 可以与 emacs-23（假定 utf-8 输入）一起使用，并且还修复了 xt-mouse.el 的现有问题。要与 emacs-22 一起使用，需要重新定义用于解码鼠标位置的函数（新定义也适用于 emacs-23）：

(defadvice xterm-mouse-event-read (around utf-8 compile activate)
  (setq ad-return-value
        (let ((c (read-char)))
          (cond
           ;; mouse clicks outside the encodable range produce 0
           ((= c 0) #x800)
           ;; must convert UTF-8 to unicode ourselves
           ((and (>= c #xC2) (< emacs-major-version 23))
            (logior (lsh (logand c #x1F) 6) (logand (read-char) #x3F)))
           ;; normal case
           (c) ) )))

将 defun 作为 .emacs 的一部分分发到您登录的所有计算机上，并修补您工作的任何机器上的 xterm。瞧！

警告：使用 xterm 鼠标模式但不将其输入视为 utf-8 的应用程序将被此补丁混淆，因为鼠标转义序列变得更长。然而，这些应用程序会严重破坏当前的 xterm，因为 x > 的鼠标位置会严重破坏。 95 看起来像 utf-8 代码，但其实不然。我会为 xterm 创建一个新的鼠标模式，但某些应用程序（gnu 屏幕！）会过滤掉未知的转义序列。 Emacs 是我使用的唯一终端鼠标应用程序，所以我认为该补丁是一个净胜，但是 YMMV。

Answer 1

xterm-262 添加了上面内联的补丁，但是，这个补丁在设计上完全被破坏了。 Rxvt-unicode 的开发人员意识到了这一点，并添加了另一个更好的扩展来报告鼠标坐标。

目前我正在努力争取对此的广泛支持。 Rxvt-unicode 和 iTerm2 已经支持这两个扩展。我为 xterm 创建了补丁（以支持 urxvt 扩展），并为 gnome-terminal、konsole 和 < code>putty 支持这两个新扩展。至于应用程序，我在 Midnight Commander 中添加了对 urxvt 扩展的支持。

请和我一起努力，尝试说服更多的终端开发者和应用程序实现这些扩展（至少是 urxvt 一个，因为另一个不能被应用程序正确自动识别）。

请参阅 http://www.midnight-commander.org/ticket/2662 了解技术详情以及进一步的指示。

Answer 2

好吧，想通了。实际上有两个问题。

首先，一些源码分析显示 xterm 将窗口的鼠标启用区域裁剪为 223x223 个字符，并为所有其他位置发送 0x0。

其次，emacs-23 能够识别 UTF-8，并且会被 x>160 和 y>94 的鼠标事件混淆；在这些情况下，xterm 对 x 和 y 的编码看起来像一个两字节的 UTF-8 字符（例如 0xC2 0x80），因此鼠标序列似乎短了一个字符。

我正在为 xterm 开发一个补丁，使鼠标事件发出 UTF-8（这既可以消除 emacs-23 的混淆，又允许终端高达 2047x2047），但我还不确定结果如何。

Answer 3

我认为导致您的解决方法（以及 v22 版本之一中包含的上游修复）在 23.2 中停止工作的问题出在 Emacs 本身内部。 23.1 可以使用 urxvt、gnu screen、putty 或 iTerm 处理第 95 列之后的鼠标点击，但 23.2 不能。将所有设置设置为 latin-1 没有什么区别。 23.1 在 xt-mouse.el 中有相同的代码。然而，src/lread.c 和 src/character.h 发生了变化，乍一看，我猜这个错误就在某个地方。至于第223栏之后会发生什么，我不知道。

为了让其他对 23.2 中的 xt-mouse 回归感到恼火的人受益，这里有一个 xterm-mouse-event-read 的修改版本，它可以使用高达第 222 列的鼠标单击（归功于 Ryan 的 >222 溢出处理，我的缺少原始修复）。这可能在 23.1 或更早版本中不起作用。

(defun xterm-mouse-event-read ()
  (let ((c (read-char)))
    (cond ((= c 0) #x100)  
       ; for positions past col 222 emacs just delivers
       ; 0x0, best we can do is stay at eol 
      ((= 0 (logand c (- #x100))) c) 
      ((logand c #xff))))) 

... 编辑：
这是 Emacs 24 的版本（bzr head）。它在 23.2 到第 222 列中再次工作，但缺少 >222 溢出 eol 处理 Ryan 建议：

(defun xterm-mouse-event-read ()
  (let ((c (read-char)))
    (if (> c #x3FFF80)
        (+ 128 (- c #x3FFF80))
      c)))

Answer 4

虽然 xterm 现在通过补丁在 utf-8 模式下工作，但这种 utf-8 hack 将以最糟糕的方式在任何其他语言环境中进行破坏，因为 unicode 字符将被删除，除非可表示。

rxvt-unicode（在 9.09 之后的版本中）具有 1015 模式，该模式使用十进制数字发送“ESC [ code ; x ; y M”形式的回复。这样做的优点是不需要应用程序进行任何探测，并且也可以在非 utf-8 语言环境中工作。