LinuxQuestions.org - [SOLVED] vim colours change slightly in xterm when a key is pressed

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - vim colours change slightly in xterm when a key is pressed (https://www.linuxquestions.org/questions/slackware-14/vim-colours-change-slightly-in-xterm-when-a-key-is-pressed-878856/)

goldfinch

05-04-2011 04:40 PM

vim colours change slightly in xterm when a key is pressed

Hi,

I'm having a problem with vim and xterm.

When I open a file and press any key, the colour scheme changes slightly.

This doesn't happen if I run a 256-colour xterm (export TERM='xterm-256color') but if TERM is set to 'xterm' (the default) I see the colour change.

Setting TERM='xterm-256color' in my ~/.bashrc is a "solution", but I'd rather not have to do that since it's never been necessary in the past (e.g., on 13.1) and I don't use any 256-color schemes for vim (usually just the default or possibly "delek").

It doesn't happen with rxvt or with Xfce's terminal.

I've tried compiling some other versions of xterm but they either exhibit the same behaviour or don't build.

I have tried running without any ~/.vimrc file just to be sure it wasn't one of my settings and I've also tried the sample file at /usr/share/vim/vimrc; the effect is the same.

Can anyone else confirm this issue?

Is there a solution besides running a 256-colour xterm?

Thanks in advance for any help with this.

elyk	05-04-2011 08:36 PM

Yeah, I notice it here too. It's obnoxious. After looking at the escape codes it sends to the terminal, I'm blaming vim. (Hint: Run `script`, open vim and trigger the bug, then quit vim and `exit`. Look at the typescript file in a hex editor.)

On xterm it does this:

1. Draws the column of ~ in bold blue (escape code "\e[1m\e[34m")
2. Queries xterm for several items. I guess this is where it figures out that xterm can support more colors.
3. On the first keypress, redraws the column of ~ in a different shade of blue (escape code "\e[94m")

It doesn't even try step 2 with rxvt. Seems like step 2 should be before step 1.

goldfinch

05-05-2011 09:25 PM

Thanks for the information.

As a temporary workaround, I've added the following to my ~/.bashrc:

Code:

case "$TERM" in

xterm*)

    alias vim='vim -T xterm-256color'

    ;;

*)

    ;;

esac

I might build an updated vim package someday but it's not at the top of my list. :)

elyk	05-05-2011 11:59 PM

I'm trying the following workaround right now, no problems yet.

Add this to your ~/.Xresources:

Code:

XTerm*termName: xterm-256color

UXTerm*termName: xterm-256color

Then do an `xrdb -load ~/.Xresources` (restarting X should also work). `xrdb -query` will print those lines back to you if it worked.

Now if you start xterm it should set $TERM to xterm-256color, and now vim should work fine.

But... for some reason it doesn't set $TERM correctly. Appears that xterm checks for "xterm-256color" in termcap instead of the more modern terminfo, and since it's not there by default, it falls back to using "xterm". So I added xterm-256color after xterm-color in /etc/termcap like this. I don't know if it's correct, but it seems to work okay so far.

Code:

goldfinch

05-06-2011 11:50 AM

Quote:

Originally Posted by elyk (Post 4347998)

So I added xterm-256color after xterm-color in /etc/termcap like this. I don't know if it's correct, but it seems to work okay so far.

Code:

I made the same modification to /etc/termcap yesterday while I was experimenting with setting the TERM variable to xterm-256color. I'm not sure if it's correct, but I didn't notice any issues with it either.

In the end, I decided to go with the alias workaround I posted last night, TERM=xterm (default), and the original /etc/termcap. I'm still not sure which solution I prefer.

With regard to xrdb, I generally use -merge instead of -load, just to be on the safe side.

rouvas

05-07-2011 07:31 PM

vim in xterm: cursor jumps over words in addition to colour changes

In my case colour changing behaviour is accompanied with an additional quirk.

If edit a line that contains the following :

Code:

"Xft:v1:antialias=true"

then with the cursor being on the "t" of true and the left arrow key is pressed, instead of positioning over to the "=" it skips to the "a" of "antialias". Similar behaviour happens in the right direction also, it skips to "t" of "true" skipping "antialias".

Both the erratic cursor positioning and the colour changes happen in XFCE and FVWM.2.6.1 (in extra).

Neither this erratic cursor positioning nor the colour changes happen when trying vim under rxvt in either window managers.

I haven't tried the workarounds presented here... I just found this topic...

slakmagik

05-07-2011 09:48 PM

Quote:

Originally Posted by elyk (Post 4347998)

But... for some reason it doesn't set $TERM correctly. Appears that xterm checks for "xterm-256color" in termcap instead of the more modern terminfo, and since it's not there by default, it falls back to using "xterm". So I added xterm-256color after xterm-color in /etc/termcap like this. I don't know if it's correct, but it seems to work okay so far.

Code:

This may really be more of a vim problem. IOW, vim is receiving TERM as 'xterm-256color' and treating it differently even though it's the exact same termcap as 'xterm'. Putting the following in ~/.vimrc also seems to fix the issue for me (and it wasn't always needed - this is some relatively recent change):

Code:

if &term =~ "xterm"

  set t_Co=256

endif

rouvas

05-09-2011 09:21 AM

Well, setting t_Co to 256 solved the "changing colors" syndrome, but had not effect on the erratic cursor movement I have as described in http://www.linuxquestions.org/questi...6/#post4349599

I have to add that if I navigate using the h,j,k,l keys instead of the arrow keys then the erratic behavior is not observed.

Could it be an xorg issue?

I have the following in /etc/X11/xorg.conf.d/90-keyboard-layout.conf :

Code:

Section "InputClass"

        Identifier "keyboard-all"

        MatchIsKeyboard "on"

        MatchDevicePath "/dev/input/event*"

        Driver "evdev"

        Option "XkbLayout" "us,el"

        #Option "XkbVariant" ""

        #Option "XkbOptions" "terminate:ctrl_alt_bksp"

        Option "XkbOptions" "grp:ctrl_shift_toggle"

        #Option "XkbModel"  "pc104"

EndSection

I don't have any other custom xorg config files.

I should also add, that for the last 10 years or so I have the following .Xdefaults entries for xterm:

Code:

xterm*background:      black

xterm*foreground:      grey

xterm*geometry: 90x43

xterm*font:    -etl-grfixed-medium-r-normal-*-*-120-*-*-c-*-iso8859-7

xterm.eightBitInput:    true

xterm*multiScroll:      on

xterm*jumpScroll:      on

xterm*ScrollBar: on

xterm*SaveLines: 2000

xterm.eightBitOutput:  true

slakmagik

05-09-2011 01:41 PM

Quote:

Originally Posted by rouvas (Post 4350969)

Well, setting t_Co to 256 solved the "changing colors" syndrome, but had not effect on the erratic cursor movement I have as described in http://www.linuxquestions.org/questi...6/#post4349599

Sorry, that wasn't to you, as such, but to the thread topic - t_Co would only effect colors. I don't know what the cursor movement fix would be. I suspect that's not a vim problem but, if it is, maybe ':h term.txt' will provide some ideas.

rouvas

05-09-2011 03:08 PM

Nothing to worry about. My response was to the thread.

About the erratic cursor movement, it must be something else. I have also trouble with the "Home" key in the rxvt command line.

I don't really understand the situation. I have the same settings for .Xdefaults and xorg.conf for the last 10-12 years or so. The only time I had queer issues like these, was when the keyboard model was faulty recognised, only it's been a *long* time that had happened.

goldfinch

05-11-2011 07:01 PM

Thanks for all the replies.

I'm going to mark this thread [SOLVED] since there are some good workarounds for the problem presented here. (They are easier than rebuilding/upgrading vim. ;))

me1040468

04-27-2012 01:59 PM

writing set term=xterm-256colors in .vimrc also works for me

elyk	08-19-2012 01:52 AM

I noticed the color changing again after testing out 14.0, so I'm looking for a better solution. This time I'm going to blame xterm. Here's what happens:

vim starts and queries termcap/terminfo/built-in settings/etc. for what the terminal supports. If the terminal identifies itself as "xterm" then the default is 8 colors.
Next, vim says to itself, "I don't really trust what termcap says, so I'll just query the terminal myself." It asks xterm how many colors it supports, among other things. This behavior must have changed between 13.1 and 13.37.
xterm is compiled with --enable-256-color so the response is always going to be 256, even though the termcap says 8 if $TERM == "xterm" (which was set by xterm).
On the next screen redraw, vim switches over to 256-color mode. Since this happens after the first screen redraw it's obvious and annoying.

So I think the solution is to prevent xterm from lying about what it supports. It should set $TERM to xterm-256color if it's going to report that it supports 256 colors. Recompiling xterm with

Code:

--disable-full-tgetent --with-terminal-type=xterm-256color

seems to work. (That first flag tells it to link against libncurses instead of libtermcap. It will use terminfo instead of the obsolete termcap so you don't have to modify /etc/termcap like in my earlier post.)

Also I noticed that rxvt identifies itself with $TERM="xterm". It doesn't respond when vim asks how many colors it supports, so you get 8 colors. Recompiling rxvt with

Code:

--enable-256-color --with-term=rxvt-256color

improves things. Try it out with

Code:

:runtime syntax/colortest.vim

from within vim.

All times are GMT -5. The time now is 12:43 AM.