I am testing the various different terminals that I tend to use to SSH into Linux boxes that I have Tmux set up on.
Basically I noticed this behavior, and I am hoping that somebody could offer an explanation of what's going on. Now it may be the case that this is specific behavior that affects the Prompt app.
I am using Vim within Tmux, and on Panic's Prompt app on my iPhone5 I was having the behavior that 256 colors were not enabling when the .vimrc
set the colors using the set t_Co=256
directive. Here, Vim was correctly displaying the colors when it was not run through Tmux. Also, OS X's Terminal.app correctly rendered the colors (I did not test PuTTY with this on windows unfortunately) with Vim in Tmux.
Then I swapped out set t_Co=256
for set term=xterm-256color
and now the colors work when using Vim through Tmux.
Note also that I tested both set -g default-terminal "xterm-256color"
and set -g default-terminal "screen-256color"
settings for Tmux and this change had no effect on behavior.
When you don't use tmux
or screen
, you only need to configure your terminal emulators to advertise themselves as "capable of displaying 256 colors" by setting their TERM
to xterm-256color
or any comparable value that works with your terminals and platforms. How you do it will depend on the terminal emulator and is outside of the scope of your question and this answer.
You don't need to do anything in Vim as it's perfectly capable to do the right thing by itself.
When you use tmux
or screen
, those programs set their own default value for $TERM
, usually screen
, and Vim does what it has to do with the info it is given.
If you want a more uniform (and colorful) behavior, you must configure them to use a "better" value for $TERM
:
tmux
Add this line to ~/.tmux.conf
:
set -g default-terminal "screen-256color"
screen
Add this line to ~/.screenrc
:
term "screen-256color"
Now, both multiplexers will tell Vim they support 256 colors and Vim will do what you expect it to do.
edit
My answer assumes that you are able to edit those configuration files but, since you are able to edit your ~/.vimrc
, I don't think that I'm that far off the mark.
edit 2
The value of the term
option (retrieved with &term
) is the name of the terminal as picked up by Vim upon startup. That name is what you are supposed to setup in your terminal emulator itself.
The value of the t_Co
option (&t_Co
) is what Vim considers to be the maximum number of colors that can be displayed by the host terminal. It is defined according to the entry corresponding to $TERM
in terminfo
:
term | t_Co
-----------------+------
xterm | 8
xterm-256color | 256
screen | 8
screen-256color | 256
When Vim starts up, it gets the value of the TERM
environment variable, queries the terminfo
database with that value and stores a number of informations on its environment in several t_…
variables among which… the number of colors available in t_Co
. Given a "legal" terminal type (one that Vim can lookup), Vim always assumes the correct number of colors.
Setting t_Co
to 256
while leaving term
to its Vim-defined value — or, more generally, setting t_Co
and/or term
to values that don't match with the host terminal — makes no sense and will likely create troubles when Vim sends a signal that is not understood by the terminal or vice-versa.
While it is entirely possible to do so, messing with t_Co
and term
in Vim is both totally useless and possibly harmful.
Again, just setup your terminal emulators and terminal multiplexers correctly. That's really all you need.
If you end up in a terminal multiplexer or a terminal emulator where you can't define a correct TERM
, then and only then you can force Vim to assume 256 colors. To that end, changing the value of t_Co
is the only thing that makes sense:
if &term == "screen"
set t_Co=256
endif
So… if you can configure each individual part:
xterm-256color
screen-256color
and you are done.
If you can't control every part, use a simple conditional in your ~/.vimrc
to set t_Co
according to &term
but don't change the value of term
.
But if you can edit a ~/.vimrc
there's no reason you can't edit a ~/.screenrc
or ~/.tmux.conf
or ~/.bashrc
or whatever.