☰

在 xterm 361 中启用鼠标协议时如何恢复 Shift+MouseButton = select？

tag-icon • tag-icon mouse xterm clipboard
在 xterm 361 中启用鼠标协议时如何恢复 Shift+MouseButton = select？

在xterm、vim或其他可以在 xterm 中使用鼠标的应用程序中，我曾经能够按住该Shift键来绕过鼠标按钮处理并进行正常的 X 选择。

随着 Debian 上 xterm 版本 361 的最新更新，这种情况不再有效。在 中vim，Shift+LeftButton 现在似乎是向下滚动。输入后printf '\e[?1000h'，我看到 Shift+LeftButton 发送了类似的内容\e[M$xy。

我该如何恢复到以前的行为？或者有什么其他方法可以正常进行 X 鼠标选择vim（或者启用鼠标协议的其他应用程序）？

FWIW，即使我禁用我能想到的所有自定义，我也可以重现：

xrdb < /dev/null
env -i DISPLAY="$DISPLAY" xterm -class MYXTerm -name myxterm -e \
  vim -u NONE -c 'set mouse=a' -c help

（并在 vim 帮助屏幕中尝试 Shift+LeftMouseButton）。

两者都包含 xterm 361 Debian 软件包和使用默认设置从源代码构建的 xterm。

编辑。重新启动后，问题消失了，但这是因为最终停用了 NumLock。所以，更正：只有当我打开 NumLock 时才会出现“问题”。

答案1

OP评论：

事实证明，“问题”只有在以下情况下才会显现出来：NumLock（mod2修改器）已打开。

和xterm #361，这是故意的：

修改使用规则转移- 覆盖键鼠标协议为了选择/粘贴将该功能限制为实际上绑定到选择/粘贴操作的鼠标按钮

xterm 使用X 工具包翻译将带有修饰符的各种键和鼠标（指针）按钮绑定到操作的资源。大多数人使用默认翻译，可能在他们的 X 资源中添加了一些内容。由于翻译功能相对静态，xterm 实现了鼠标协议通过检查用于选择/粘贴的操作中看到的事件：

在#361（见来源），xterm 在启动时检查翻译资源，以确定哪些指针（鼠标）按钮绑定到这些事件，并且当仅使用 Shift 修饰符接收到匹配的按钮事件时，它将覆盖鼠标协议并执行 select/粘贴操作（因为它已经做了相当长一段时间了）。

更改的原因是允许应用程序获得一些组合（例如转移使用滚轮鼠标）接收他们可以解释的转义序列。

翻译资源没有描述这种对转变的特殊处理，例如，

                       ~Meta <Btn1Down>:select-start() \n\
                     ~Meta <Btn1Motion>:select-extend() \n\

但是 xterm 的鼠标协议依赖于能够接收那些翻译中并未真正明确定义的事件。我注意到#361之后它没有治疗运动事件与这个改变的方案一致（修复将在#362中）。

我一般使用 xmodmap 来定义元键，以便我可以使用这些翻译。对于 macOS 上的显示器，我有这样的：

xmodmap:  up to 2 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x40),  Shift_R (0x44)
lock        Caps_Lock (0x41)
control     Control_L (0x43),  Control_R (0x46)
mod1        Alt_L (0x42),  Alt_R (0x45)
mod2        Meta_L (0x3f),  Meta_R (0x47)
mod3      
mod4      
mod5

而 Debian 上显示的未修改的 xmodmap 则不同：

xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

以便元在后者中可以访问，但不太方便：它需要几个模式开关。

还有其他问题领域需要探索，例如待处理的拉取请求不要忽略 _XtMatchUsingDontCareMods 中缺少的非标准修饰符，这会干扰使用mod2为了元（通过消除 xterm 转换为转义序列的一些事件）。

相关内容