The new vim has a nifty feature to find out whether the terminal has 256-color capability. Now xterm has it, but the terminfo (xterm) doesn't show it. So what happens when starting vim 7 in xterm with TERM=xterm and some file where you can see some syntax highlighting is this: vim starts with t_Co=8, opens the file, applies the 8-color highlighting vim then magically finds out that xterm can do more vim changes t_Co to 256, reapplies syntax highlighting to use 256 colors This is usually so fast that one will only notice some flickering, which can still be annoying. This cannot be stopped by any command like 'set t_Co=8' in .vimrc, since it happens later. Solution: Use TERM=xterm-256color when starting vim OR remove the old terminfo-file for xterm and use a symlink to xterm-256color instead.
If it really is a bug, it's more a terminfo-bug than a vim- or xterm-bug.
Incorrect, there is no terminfo bug here and moreover no "old terminfo-file" to remove; if vim behaviour is suboptimal when using the "xterm" description use the "xterm-256color" one.
xterm provides a control sequence to query for the control sequence it sends given the termcap/terminfo name, and vim use it when possible. A guess is that vim first gets the "colors" cap from terminfo and then update it querying xterm; the problem arises because xterm always returns for the "colors" cap the maximum numbers of colors supported, not the minimum between it and the current value from the terminfo description. Now it's questionable if xterm should do the latter or vim should not request the "colors" cap or the current vim behaviour is fine even if suboptimal, Thomas?
It's not a problem with xterm. Given that the terminfo provides the information, I'd regard it as a quirk of vim. xterm is telling vim how many colors it supports (and noting that this query is a feature requested by Bram Moolenaar, and that xterm has no way to determine how the application is configured), it's up to vim to decide whether to ignore the terminfo and .vimrc or not. It's not necessarily a bug in vim either, since its order of initialization is going to be determined by a lot of factors (I can think of some analogous issues in other programs).
In my opinion this is something vim messes up in its startup sequence. If it really must determine the terminal's capacities it should do so before doing any output. Or better before .vimrc, so scripts in there will have the correct t_Co settings. My solution so far: Adding this line in .Xdefaults XTerm*termName: xterm-256color I don't know why xterm shouldn't advertise its capabilities...
Adding this line to .Xdefaults affect other programs too - for ex. my mc fail to understand Fx-keys and Meta-x-keys when TERM=xterm-256color. Of course I can fix it in mc configuration, but I suppose many other programs can change their behaviour too... Why not solve this by adding this line to ~/.vimrc instead: set term=xterm-256color
I had a hard time reproducing my own bug. I've hacked around too much already. Ok, setting TERM to something else is not the best option, I can see that. I am now happy with this solution in .vimrc: if &term == "xterm" set term=xterm-256color endif This also allows to adjust the highlighting and such with a statement like this: if &t_Co == 256 hi Comment ctermfg=12 endif Thanks for your help, I'd like to consider this bug closed.
