在GNU屏幕下运行vim时，我发现CTRL带有箭头和Pg *键的组合无法正常工作。
我正在使用Ubuntu 10.10 vim-gnome软件包。
在另一台也运行Ubuntu的计算机上，它确实没有问题。不幸的是，我现在没有该配置。
这里有一个相关的问题：如何在Vim中修复Ctrl +箭头？
但是，建议的解决方案是重新映射vim的键绑定以与终端仿真器（在这种情况下为PuTTY）一起使用。我不记得做任何事情了，并且怀疑有一个屏幕配置选项可以解决此问题。
在gnu屏幕邮件列表上还有一个线程，它表明通过vim运行$ TERM=xterm vim是适当的修复或解决方法。确实可以，但是我有点担心可能会有副作用。听起来还不太熟悉，无法成为我在另一台机器上设置的解决方案（如果需要解决方案）。
Answers:
正如他在更新中指出的那样，添加term xterm到~/.screenrc文件似乎可以解决此问题。
screen不仅仅传播$TERM环境变量而不是用覆盖它"screen"。大概在某些情况下，拥有重要的东西$TERM == screen。
TERM=screen是内部运行的应用程序正在Screen终端内部进行通信：它们发送和接收的控制序列是Screen的控制序列，而不是正在显示Screen的任何终端的控制序列。由于您可以分离Screen会话并将其重新连接到其他类型的终端，因此此间接层是必需的。
xterm？
infocmp screen和infocmp xterm，并且屏幕转义序列与所述的xterm转义序列。我没有要提供的细分；大多数应用程序都不会介意，但有些应用程序可能会令人讨厌。
还有其他几种设置终端的方法，这些终端可以在运行的进程中工作：
在正在运行的屏幕实例中，按^A- :并发出命令term xterm将导致该实例下新打开的屏幕以其$TERM环境变量设置为xterm; 开始。这将依次传播到调用的vim实例。这些vim实例将显示有关CTRL-combos的正确行为。我尚未发现此策略的任何副作用。此命令不会影响现有屏幕。当然，此命令可以在~/.screenrc文件中使用，因此有可能在另一台计算机上使用了此方法。
在正在运行的vim实例中，该命令set term=xterm将使CTRL-combos在该vim实例中工作。由于我尚不了解的原因，这具有断开X剪贴板（即@*和@+）的副作用。有趣的是，:set term=screen在以开头的vim实例中执行命令时，剪贴板也会发生副作用$TERM=xterm。
潜在的问题是screen实际终端（由TERM外部的环境变量标识screen）与内部的模拟之间的映射screen不完整。
如果您碰巧对其进行了测试（使用vttest或tack），则可能会发现以下缺陷：
试图通过设置来解决这些问题term中.screenrc有它仅适用于缺点给定的实际终端，而不是移植到其他终端实现。该文件笔记
不推荐将术语命令用于非默认目的。
使用screen 文档中的此功能还有另一种解决方案（具有不同的缺点）：
当screen试图找出自己的终端名称时，它首先寻找一个名为screen的条目。term，其中term是
$TERM变量的内容。如果不存在这样的条目，则屏幕尝试screen（screen-w如果终端很宽（132列或更多），则尝试，）。如果甚至找不到此条目，则将vt100其用作替代项。
ncurses针对这种情况提供了一些有用的备用终端说明，例如screen.xterm-new，以修复屏幕映射中的问题。在实践中，我使用TERM=xterm-new，并在运行屏幕时获得功能键的可用映射。
回到屏幕的term设置，在测试中您可能会注意到映射仍然存在问题，这些替代方法已解决了这些问题。如果可以使用来获得准确的终端描述term，则这些替代方法将是的简单别名screen。他们不是。
ncurses的并没有提供screen.xterm（原文如此），因为：
TERM=xterm被广泛用于不同于xterm的终端仿真器；添加此映射只会加剧这种情况（例如，在ncurses常见问题解答中，例如，为什么不只将TERM设置为“ xterm”？）screen.xterm不太可能安装在远程系统上（请参阅终端数据库中自2015年6月起的更改注释）。总体而言，使用替代名称是对term您使用的改进.screenrc：它解决的问题比创建的要多。反之亦然term。
term xterm到我的~/.screenrc文件中为我修复了该问题。再次感谢！