在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 转换为转义序列的一些事件）。