10

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

Community
  • 1
intuited
  • 3,538
  • +1 - I was having the same problem and - as you suggested - adding term xterm to my ~/.screenrc file fixed it for me. Thanks again! – Justin Ethier Feb 24 '11 at 18:59

3 Answers3

5

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

Justin Ethier
  • 16,806
  • 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 Feb 26 '11 at 04: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. – Gilles 'SO- stop being evil' Mar 26 '11 at 12:31
  • @Gilles: Thanks, I suspected something like that. What sorts of problems could arise from resetting it to xterm? – intuited Mar 26 '11 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. – Gilles 'SO- stop being evil' Mar 27 '11 at 17:32
4

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.

Thomas Dickey
  • 76,765
2

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.

phunehehe
  • 20,240