Fixing CTRL-* in vim under GNU screen

Question

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).

Answer 1

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

Answer 2

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.

Answer 3

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.