When running vim under GNU screen, I'm finding that combinations of CTRL with the arrow and Pg* keys don't work as expected.

I'm using the Ubuntu 10.10 vim-gnome package.

On a different machine, also running Ubuntu, this did work without problems; unfortunately I don't have that configuration available to me now.

There is a related question here: How to fix Ctrl + arrows in Vim?

However, the suggested solution there is to remap vim's keybindings to work with the terminal emulator, in that case PuTTY. I don't recall doing anything of the sort, and suspect that there is a screen configuration option which will resolve this issue.

There's also a thread on the gnu-screen mailing list which suggests that running vim via $ TERM=xterm vim is an appropriate fix or workaround. This does work, but I'm a bit concerned that there might be side effects. It also doesn't sound familiar enough to be the solution I set up on the other machine (if a solution was necessary).

  • +1 - I was having the same problem and - as you suggested - adding term xterm to my ~/.screenrc file fixed it for me. Thanks again! Commented Feb 24, 2011 at 18:59

3 Answers 3


As intuited stated in his update, adding term xterm to the ~/.screenrc file seems to fix this problem.

  • Well.. yes, but I'm holding out for some sort of explanation as to why screen doesn't just propagate the $TERM environment variable instead of overriding it with "screen". Presumably there are some circumstances where it's important to have $TERM == screen.
    – intuited
    Commented Feb 26, 2011 at 4:56
  • 3
    @intuited: The reason Screen sets TERM=screen is that applications running inside are communicating inside a Screen terminal: the control sequences they send and receive are those of Screen, not those of whatever terminal Screen itself is being displayed. Since you can detach a Screen session and reattach it to a different type of terminal, this layer of indirection is necessary. Commented Mar 26, 2011 at 12:31
  • @Gilles: Thanks, I suspected something like that. What sorts of problems could arise from resetting it to xterm?
    – intuited
    Commented Mar 26, 2011 at 20:10
  • 1
    Not much, because xterm and screen are mostly compatible. But each has a few capabilities that the other one doesn't, and if you lie to applications, they might use a capability that doesn't actually work. Compare the output of infocmp screen and infocmp xterm, and the screen escape sequences with the xterm escape sequences. I don't have a breakdown to offer; most applications won't mind, but a few might behave annoyingly. Commented Mar 27, 2011 at 17:32

The underlying problem is that the mapping done by screen between the actual terminal (identified by the TERM environment variable outside screen) and the emulation within screen is incomplete.

If you happen to test it (using vttest or tack), you may notice deficiencies for

  • colors
  • special keys

Attempting to fix these problems by setting term in .screenrc has the drawback that it works only for a given actual-terminal, and is not portable to other terminal implementations. The documentation notes

The use of the term command is discouraged for non-default purpose.

There is another solution (with a different drawback), using this feature from screen documentation:

When screen tries to figure out a terminal name for itself, it first looks for an entry named screen.term, where term is the contents of your $TERM variable. If no such entry exists, screen tries screen (or screen-w, if the terminal is wide (132 cols or more)). If even this entry cannot be found, vt100 is used as a substitute.

ncurses provides several useful alternate terminal descriptions for this case, e.g., screen.xterm-new, to repair problems in screen's mapping. In practice, I use TERM=xterm-new, and when running screen, get a usable mapping of function keys.

Referring back to screen's term setting, in testing you may notice that there are still problems with the mapping, which are addressed in these alternatives. If it were possible to get an accurate terminal description using term, these alternatives would be simple aliases to screen. They are not.

ncurses does not provide screen.xterm (sic) because:

  • TERM=xterm is misused widely for terminal emulators which differ from xterm; adding this mapping would only aggravate that situation (see for example Why not just use TERM set to "xterm"? in the ncurses FAQ)
  • the alternative name screen.xterm is less likely to be installed on remote systems (see change comment from June 2015 in the terminal database).

On the whole, however, using the alternate names is an improvement over using term in your .screenrc: it solves more problems than it creates. The reverse is true of the term setting.


There are a couple of other ways to set the terminal which work in running processes:

  • In a running screen instance, pressing ^A-: and issuing the command term xterm will cause newly opened screens under that instance to start with their $TERM environment variable set to xterm; this will in turn propagate to invoked vim instances. These vim instances will display proper behaviour with regard to CTRL-combos; I've not yet discovered any side effects of this strategy. This command does not affect existing screens. This command can of course be used in a ~/.screenrc file, so it's possible that this method was used on the other machine.

  • In a running vim instance, the command set term=xterm will make CTRL-combos work in that vim instance. This has the side effect of disconnecting the X clipboard (i.e. @* and @+) for reasons that I do not yet understand. Interestingly, the clipboard side effect also happens when the command :set term=screen is executed in a vim instance started with $TERM=xterm.

  • This answer was taken from the OP's updates. All I did was to reformat and reword a little bit.
    – phunehehe
    Commented Mar 26, 2011 at 8:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .