I am facing problems with my configuring screen.

My screen.rc is very simple and looks like this:

altscreen on
termcapinfo xterm ti@:te@

I wanted to configure screen to have the same behavior as if I connected directly using SSH client like MobaXterm. So what I wanted to achieve was:

  • A possibility to scroll in vim (without using set mouse a) with mouse
  • Scrolling terminal output with mouse (without Ctrl + A Esc)
  • After exiting vim and other editors etc. I want to see my previous commands, not the vim output nor have my screen cleared.

Also configuring .vimrc (and similar local config files) is impossible because I'm using screen to connect to many many machines and I am not able to modify .vimrc on all of them.

I found out that achieving all of this is impossible. So with those two lines in my .screenrc I am able to scroll the terminal output but in vim I have to use the keyboard - ok.

So, going straight to the problem.

When I close vim I get a very strange behavior. The output of the console is like it was before opening vim so it's what I want. But the prompt is at the top of the window instead of being after my last command (running vim). So I'm writing on top of some previous output.

I hope you understand. Do you know how to fix it? Any help would be appreciated.

I don't know if it is meaningful but I am connecting using MobaXterm to a virtual machine when I have my screen configured. Maybe it's also related to SSH, who knows.

Edit: I tried also another ssh clients like Putty and it's the same

  • try using in the command line the command reset to fix it temporarily. It could be your TERM is not well defined. – Rui F Ribeiro Nov 19 '15 at 11:08
  • echo $TERM shows xterm-256color – damian Nov 19 '15 at 11:11
  • seems ok...using an OS/X desktop? – Rui F Ribeiro Nov 19 '15 at 11:15
  • My desktop is Windows – damian Nov 19 '15 at 11:18

The symptom described is from a rc (restore-cursor) escape sequence. Thinking about it, the likely source of the problem is vim:

  • with the given .screenrc, the screen program simulates the xterm alternate screen feature.
  • that is done using the terminfo smcup and rmcup (termcap ti and te) control sequences
  • when switching to the alternate screen, xterm (a) saves the cursor position, (b) clears the alternate screen and (c) displays the alternate screen.
  • when switching from the alternate screen, xterm (a) restores the cursor position for the normal screen and (b) displays the normal screen.
  • those operations are done in single control sequences, not split up. In the terminal description, you may (infocmp output) see a 1049.
  • the screen program simulates those operations.
  • however, unlike xterm, it does not use a single variable for the saved/restored cursor position: A quick check shows that if
    • I save the cursor position (with tput sc),
    • switch to/from the alternate screen (tput smcup
    • followed by tput rmcup), and finally
    • restore the cursor position (tput rc),
    • then the cursor goes to the position saved by tput sc.

vim -- and plugins of vim -- can send escape sequences. It seems that something during exit of vim is sending the escape sequence for restoring the cursor. In a quick check here, vim behaved properly (but configurations and versions differ). So I'd check on the plugins.

If I were debugging this case, I would capture the characters sent to the screen (using script for instance) and look for the most commonly used sequences for rc:

  • escape7
  • escape[u

It would be nice if screen more closely matched xterm's behavior, but ultimately it seems there is a problem with vim sending unexpected save/restore-cursor sequences.

Related reading:


It turned out the problem was caused by a stupid line in .bashrc

TERM=xterm; export $TERM

so after running screen it had TERM=xterm instead of TERM=screen. After removing this line the problem disappeared.


I found a kind of solution here: How to configure screen-restore in a terminal? so for vim:

For vim you can include something like

set t_ti= t_te=

in you ~/.vimrc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.