The problem description mentions "the terminal retains some properties like background color". That could refer to the back color erase feature, which PuTTY supports. When the screen is erased, the terminal will fill the background (on the erased portion) with the current background color.
On first glance, the alternate screen feature does not appear to be related, however. I can produce a problem using PuTTY and vim using the "morning" colorscheme with or without PuTTY's alternate-screen feature disabled. On exit, the screen has the same gray background as in vim. If I follow that by
tput sgr0
then that command resets the colors, so that new text is written with the terminal's default background color (as expected).
Looking at the escape sequences sent by vim on exit shows nothing unusual — in the terminal description (using unmap
to make them in readable form):
\n
\E[1m
\E[38;5;130mendif
\E[0m
\E[30m
\E[47m
\E[24;63H1,1
\E[11CTop
\E[1;1H
\E[?25h
\E[?25l
\E[24;63H
\E[K
\E[24;1H:
\E[?25hq
\E[?25l
\E[?25h\r
\E[?25l
\E[24;1H
\E[K
\E[24;1H
\E[?1l
\E>
\E[?25h
\E[2J
\E[?47l
That is, vim sends sgr0
(\E[0m
) just after setting the background to gray (\E[38;5;130m
). Doing that should reset the colors. But it does not. There are several other operations before vim sends the two-part escape sequence in rmcup
\E[2J
\E[?47l
which should clear the (alternate) screen and switch back to the normal screen. The corresponding capability in xterm
is
\E[?1049l
which combines the two operations. Seeing that, there are two problems in PuTTY which together produce the problem:
- the colors are not reset as expected, and
- the color is applied to setting the background on the normal screen.
It just happens to work with TERM=xterm
, using the 1049
code, because PuTTY's developers apparently tested that. For instance, if that restores the normal screen's colors (but not using the 47
code), then you would see exactly this problem.
Further reading: