FZF colors no longer match your color scheme

[blayz3r]

• [X ] I have fzf 0.23.0 or above
• [X ] I have read through https://github.com/junegunn/fzf.vim/blob/master/README.md
• [ X] I have read through https://github.com/junegunn/fzf/blob/master/README-VIM.md
• [ X] I have read through the manual page of fzf (man fzf)
• [ X] I have searched through the existing issues

After v0.24

Before v0.18

" Customize fzf colors to match your color scheme
let g:fzf_colors =
            \ { 'fg':      ['fg', 'Normal'],
            \ 'bg':      ['bg', 'Normal'],
            \ 'hl':      ['fg', 'Comment'],
            \ 'fg+':     ['fg', 'CursorLine', 'CursorColumn', 'Normal'],
            \ 'bg+':     ['bg', 'CursorLine', 'CursorColumn'],
            \ 'hl+':     ['fg', 'Statement'],
            \ 'info':    ['fg', 'PreProc'],
            \ 'border':  ['fg', 'Ignore'],
            \ 'prompt':  ['fg', 'Conditional'],
            \ 'pointer': ['fg', 'Exception'],
            \ 'marker':  ['fg', 'Keyword'],
            \ 'spinner': ['fg', 'Label'],
            \ 'header':  ['fg', 'Comment'] }

[junegunn]

Works for me.

[blayz3r]

I am windows 10 maybe that's why

[blayz3r]

The code below looks redundant now

" Customize fzf colors to match your color scheme let g:fzf_colors = \ { 'fg': ['fg', 'Normal'], \ 'bg': ['bg', 'Normal'], \ 'hl': ['fg', 'Comment'], \ 'fg+': ['fg', 'CursorLine', 'CursorColumn', 'Normal'], \ 'bg+': ['bg', 'CursorLine', 'CursorColumn'], \ 'hl+': ['fg', 'Statement'], \ 'info': ['fg', 'PreProc'], \ 'border': ['fg', 'Ignore'], \ 'prompt': ['fg', 'Conditional'], \ 'pointer': ['fg', 'Exception'], \ 'marker': ['fg', 'Keyword'], \ 'spinner': ['fg', 'Label'], \ 'header': ['fg', 'Comment'] }

[blayz3r]

https://github.com/junegunn/fzf.vim/issues/1141

[blayz3r]

https://github.com/junegunn/fzf/issues/1858

[blayz3r]

Latest update destroyed everything.....

[junegunn]

What do you mean by "Latest update"?

[blayz3r]

https://github.com/junegunn/fzf/commit/7915e365b364af4c4287e35f4697f6e3cfe33284, Sorry not sure what issue goes here or the other repo

[junegunn]

I see. I reverted the commit.

/cc @wjrogers

[kelleyma49]

Using just the --height option seems to work fine (see above.) It must be an issue with rendering in the popup. The --height option uses the light renderer on Windows, if available.

I'm not a vim expert, so can someone give me the simpliest way to run fzf.exe in a vim popup window?

[junegunn]

@kelleyma49 Hi, thanks for chiming in. The latest version of the Vim plugin runs fzf inside a popup window by default.

If you don't use Vim at all and are not familiar with its plugin ecosystem. Here is an easy way to try it:

1. Git clone https://github.com/junegunn/fzf
2. Load the file with the command: :source <CLONE DIR>/plugin/fzf.vim
3. Run :FZF
   • It will use fzf in your PATH if available

Since the Vim plugin determines the size of the popup window, it doesn't use --height option at all. It actually appends --no-height at the end of the option string.

[junegunn]

After reading #1141, now I realized that the image you titled "After v0.24" is actually showing the right colors. The colors shown in "Before v0.18" are incorrect. So this is not an issue.

[blayz3r]

After reading #1141, now I realized that the image you titled "After v0.24" is actually showing the right colors. The colors shown in "Before v0.18" are incorrect. So this is not an issue.

Isn't setting g:fzf_colors supposed to match the vim colorscheme... If not how do you get FZF to match your colorscheme after 0.24

[junegunn]

I don't have a Windows 10 PC to test this, so I can only guess. The colors in the first picture are not the default colors of fzf, which made me think that the variable was playing its part. However, it's indeed strange that the background color is not changed. A few things to check:

1. Have you tried switching to a different color scheme and run fzf with it? No difference?
2. What is the output of :echo fzf#wrap().options? Does it contain proper --color configuration?
3. If so, open up a terminal inside Vim (:terminal) and run fzf with the options. Are the colors correct? Do you see the same colors when you run the same command on Command Prompt (cmd) outside of Vim?
4. Do you see no difference in colors when you unlet g:fzf_colors?

[blayz3r]

echo fzf#wrap().options shows:

--color=bg+:236,bg:235,spinner:170,hl:59,fg:145,header:59,info:180,pointer:170,marker:204,fg+:145,prompt:170,hl+:170

The colors match what is in the terminal

I am starting to think it is a limitation of the terminal?

unletting g:fzf_colors matches my colorscheme slightly better

Is this relevant: https://github.com/junegunn/fzf/issues/1858#issuecomment-586661586

[junegunn]

So these are 256 ANSI colors rather than 24-bit true colors,

--color=bg+:236,bg:235,spinner:170,hl:59,fg:145,header:59,info:180,pointer:170,marker:204,fg+:145,prompt:170,hl+:170

and the difference you see (such as the background color) is due to the limitation of the 256-color palette.

The latest version of fzf does support 24-bit colors on Windows, but the Vim plugin is not generating 24-bit colors according to g:fzf_colors on Windows because not all terminals on Windows are capable of displaying 24-bit colors. See https://github.com/junegunn/fzf/pull/1793.

This patch will make g:fzf_colors generate 24-bit colors (i.e. :echo fzf#wrap().options will show something like --color=bg+:#3F3F3F,bg:#4B4B4B,border:#6B6B6B,spinner:#98BC99 ...), but I have no idea if GVim on Windows is able to display the colors.

diff --git a/plugin/fzf.vim b/plugin/fzf.vim
index 14d0276..1eef9e3 100644
--- a/plugin/fzf.vim
+++ b/plugin/fzf.vim
@@ -303,7 +303,7 @@ function! s:common_sink(action, lines) abort
 endfunction
 
 function! s:get_color(attr, ...)
-  let gui = !s:is_win && !has('win32unix') && has('termguicolors') && &termguicolors
+  let gui = has('gui_running') || has('termguicolors') && &termguicolors
   let fam = gui ? 'gui' : 'cterm'
   let pat = gui ? '^#[a-f0-9]\+' : '^[0-9]\+$'
   for group in a:000

[blayz3r]

So these are 256 ANSI colors rather than 24-bit true colors,

--color=bg+:236,bg:235,spinner:170,hl:59,fg:145,header:59,info:180,pointer:170,marker:204,fg+:145,prompt:170,hl+:170

and the difference you see (such as the background color) is due to the limitation of the 256-color palette.

The latest version of fzf does support 24-bit colors on Windows, but the Vim plugin is not generating 24-bit colors according to g:fzf_colors on Windows because not all terminals on Windows are capable of displaying 24-bit colors. See junegunn/fzf#1793.

This patch will make g:fzf_colors generate 24-bit colors (i.e. :echo fzf#wrap().options will show something like --color=bg+:#3F3F3F,bg:#4B4B4B,border:#6B6B6B,spinner:#98BC99 ...), but I have no idea if GVim on Windows is able to display the colors.

diff --git a/plugin/fzf.vim b/plugin/fzf.vim
index 14d0276..1eef9e3 100644
--- a/plugin/fzf.vim
+++ b/plugin/fzf.vim
@@ -303,7 +303,7 @@ function! s:common_sink(action, lines) abort
 endfunction
 
 function! s:get_color(attr, ...)
-  let gui = !s:is_win && !has('win32unix') && has('termguicolors') && &termguicolors
+  let gui = has('gui_running') || has('termguicolors') && &termguicolors
   let fam = gui ? 'gui' : 'cterm'
   let pat = gui ? '^#[a-f0-9]\+' : '^[0-9]\+$'
   for group in a:000

New output

--color=bg+:#2C323C,bg:#282C34,spinner:#C678DD,hl:#5C6370,fg:#ABB2BF,header:#5C6370,info:#E5C07B,pointer:#C678DD,marker:#E06C75,fg+:#ABB2BF,prompt:#C678DD,hl+:#C678DD

Yes, that change would fix the issue

[blayz3r]

So these are 256 ANSI colors rather than 24-bit true colors,

--color=bg+:236,bg:235,spinner:170,hl:59,fg:145,header:59,info:180,pointer:170,marker:204,fg+:145,prompt:170,hl+:170

and the difference you see (such as the background color) is due to the limitation of the 256-color palette.

The latest version of fzf does support 24-bit colors on Windows, but the Vim plugin is not generating 24-bit colors according to g:fzf_colors on Windows because not all terminals on Windows are capable of displaying 24-bit colors. See junegunn/fzf#1793.

This patch will make g:fzf_colors generate 24-bit colors (i.e. :echo fzf#wrap().options will show something like --color=bg+:#3F3F3F,bg:#4B4B4B,border:#6B6B6B,spinner:#98BC99 ...), but I have no idea if GVim on Windows is able to display the colors.

diff --git a/plugin/fzf.vim b/plugin/fzf.vim
index 14d0276..1eef9e3 100644
--- a/plugin/fzf.vim
+++ b/plugin/fzf.vim
@@ -303,7 +303,7 @@ function! s:common_sink(action, lines) abort
 endfunction
 
 function! s:get_color(attr, ...)
-  let gui = !s:is_win && !has('win32unix') && has('termguicolors') && &termguicolors
+  let gui = has('gui_running') || has('termguicolors') && &termguicolors
   let fam = gui ? 'gui' : 'cterm'
   let pat = gui ? '^#[a-f0-9]\+' : '^[0-9]\+$'
   for group in a:000

I can close this if you commit this change....

[junegunn]

Unfortunately, it's not that simple. I have a Windows 2016 server and GVim running there does not properly display 24-bit colors in its terminal (it's probably a limitation of old cmd.exe) so this change makes the colors way worse.

• Can we be sure that 24-bit colors are supported on Windows 2019?
• If so, is there a way in Vim to find out if we're running Windows 2019?

/cc @janlazo

[blayz3r]

From what I gather windows 10 terminals/consoles have had 24 bit color support by default since 2017.

2016 initial implementation. https://devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/ but I'll let others chime in

2017 widespread support https://github.com/Microsoft/WSL/issues/2178#issuecomment-305314265

[janlazo]

On Vim, there is has('conpty') and termmode option from https://github.com/vim/vim/commit/aa5df7e3127dff6b7336df0903f5c569a40eb174. termmode is renamed to termwintype in https://github.com/vim/vim/commit/c6ddce3f2cf6daa3a545405373b661f8a9bccad9. There is an open PR on Neovim for has('conpty').

If https://github.com/microsoft/terminal is the terminal for cmd.exe and powershell.exe on recent versions of Windows 10, then the earliest stable v1.x release is https://github.com/microsoft/terminal/releases/tag/v1.0.1401.0, released on May 19, 2020.

[blayz3r]

@junegunn as an aside does GFiles? work on Windows 2016 server

[junegunn]

@blayz3r Yes, both :GF and :GF? work as expected.

[blayz3r]

:GF?

Even the preview:

I'll debug on my end then

[ecmrauh]

I had a similar problem on Linux (Debian 10, KDE). In my terminal (Konsole), everything worked as expected, but in GVim, the colors didn't match the color scheme (as in your screenshot above). After setting ...

set termguicolors

... in my .gvimrc (or .vimrc, that doesn't matter), the colors matched the color scheme in GVim.

[dkarter]

I'm on Mac and not sure if this is related, but I run fd as the FZF_DEFAULT_COMMAND:

let $FZF_DEFAULT_COMMAND = 'fd --type f --hidden --follow --color=always -E .git --ignore-file ~/.gitignore'

Since updating to the latest version today e9d62b4c873f5f207202b4ba5bbd63de7003a0d3, all colors started looking off:

[junegunn]

@dkarter

Try starting a terminal buffer and run fzf there.

:term

echo $TERM
fzf

• What is the value of $TERM there?
• Do you see the same colors?
• You might want to configure the color palette of the terminal buffer using g:terminal_ansi_colors (or g:terminal_color_* on Neovim)
  • e.g. https://github.com/junegunn/dotfiles/blob/18e886d73eac4866724cfcb00ef168dffd5be0d4/vimrc#L330-L360
• Do you have g:fzf_colors defined?
  • https://github.com/junegunn/fzf/blob/master/README-VIM.md#explanation-of-gfzf_colors

[dkarter]

@junegunn Thank you so much! You are correct the issue was caused due to a PR on my colorscheme that removed those g:terminal_color_* settings https://github.com/rakr/vim-one/pull/104

[blayz3r]

On Vim, there is has('conpty') and termmode option from vim/vim@aa5df7e. termmode is renamed to termwintype in vim/vim@c6ddce3. There is an open PR on Neovim for has('conpty').

If https://github.com/microsoft/terminal is the terminal for cmd.exe and powershell.exe on recent versions of Windows 10, then the earliest stable v1.x release is https://github.com/microsoft/terminal/releases/tag/v1.0.1401.0, released on May 19, 2020.

So this issue can be closed if we add the above condition to:

 function! s:get_color(attr, ...)
-  let gui = !s:is_win && !has('win32unix') && has('termguicolors') && &termguicolors
+  let gui = has('gui_running') || has('termguicolors') && &termguicolors
   let fam = gui ? 'gui' : 'cterm'
   let pat = gui ? '^#[a-f0-9]\+' : '^[0-9]\+$'
   for group in a:000

[kian1245]

Latest update destroyed everything.....

hello use ubuntu or debian

[Kamholtz]

It seems that this is blocked by a need to maintain compatibility with cmd.exe but not having a way to determine whether the terminal supports 24 bit colours or not. Can I suggest adding an option g:fzf_force_24_bit_colors to allow windows users to get around this issue in the meantime? I have made a pull request on the fzf repository here:

https://github.com/junegunn/fzf/pull/2889