Weird graphical issues in tmux

[athaeryn]

I'm getting some weird graphical issues when using fzf in a tmux session. I don't have any problems when using it outside of tmux. I'm on OS X using zsh in iTerm2.

[junegunn]

Thanks for the report. I'm aware of the issue. It only seems to happen when $TERM is set to 256-color, such as xterm-256color. The problem goes away if I strip out the trailing -256color when running fzf, but then fzf will use the default terminal colors (which is not necessarily a bad thing though). I'll try to look for a workaround. If I can't find one, I should probably update the install script to generate ~/.fzf.zsh that overrides $TERM variable when running fzf inside tmux.

[junegunn]

Hmm, further investigation shows that the problem appears even when $TERM is set to xterm. But I see no problem when it's set to screen or screen-256color. (The latter, however, does not display 256-colors which seems to be the limitation of Ruby curses library)

[junegunn]

http://www.economyofeffort.com/2013/08/03/zsh-tmux-vim-and-256-color-madness/
FYI: the above article suggests that you should use screen-256color instead of xterm-256color.

[junegunn]

Could you update fzf, set $TERM to screen-256color and test it again?

[drn]

I had the same problem and updated $TERM to screen-256color in my tmux.conf. (set -g default-terminal "screen-256color"). Confirmed that this fixed it.

However, I do remember that I specifically set $TERM to xterm-256color because I had some issue with using my mouse in vim running in tmux on iterm2. I'll follow up on this thread if I come across the issue I had again, but the change looks like it fixed it.

Thanks for the great tool! I rely on ctrlp so much in vim that I know I'll be using this heavily.

[junegunn]

@DarrenLi Hey, thanks for letting me know! I also run vim with tmux on iTerm2 where TERM is set to screen-256color, and haven't run into any problem with mouse.

@athaeryn Any progress?

[justinmk]

I have the same problem on msys2 which uses mintty--and I'm not running tmux.

$ ruby --version
ruby 2.0.0p353 (2013-11-22 revision 43784) [x86_64-msys]

I tried the following:

$ export TERM=screen-256color
$ export TERM=screen

I also tried that in my ~/.profile and restarting mintty. No effect.

msys2 is still kind of new, so maybe it's not worth worrying about, but I'd be interested to know any other way of forcing 16 colors.

[junegunn]

@justinmk Okay, I'll see what I can do. In the meantime, what is the default value of TERM on it when you don't explicitly set it? I don't think you should set TERM to screen or screen-256color unless you're using tmux or screen.

[justinmk]

what is the default value of TERM on it when you don't explicitly set it

By default:

$ echo $TERM
xterm-256color

I don't think you should set TERM to screen or screen-256color unless you're using tmux or screen.

Yeah, I was just experimenting with the suggestions in this thread.

[junegunn]

@justinmk Currently fzf simply decides to use 256-color when the value of $TERM includes "256". Could you try again with $TERM set to xterm? (And yeah, I should probably add another option to force using 16-color regardless of $TERM)

[junegunn]

@justinmk Yesterday I had a chance to work on fzf on Windows 7. Fixed up some issues with escape key sequences there. But other than that, it seemed to work fine on putty and Cygwin terminal with both xterm and xterm-256color.

[justinmk]

Ok, then it's just something wrong with msys2's mintty, or something. export TERM=xterm does force 16 colors, but the "blackout" effect still occurs for partial higlights (except the highest-ranked match, ie the last line). Thanks!

[justinmk]

And the new --no-256 option also correctly forces 16 colors. In case it helps, here's a screenshot of what I'm seeing:

fzf --no-256

The last line highights nicely, but the others do not. Any chance it would be possible for --no-256 to use the same mechanism (colors...?) to highlight the lower-ranked matches?

Probably msys2 is just broken in some way, but I'm not above limping along with the bare minimum if I can. The search works flawlessly, after all :)

[junegunn]

@justinmk Phew, the new --black option will fix the problem (no need for --no-256). See the commit message for the details.

[justinmk]

Works beautifully with --black option:

Thanks!