FVim reports neither a GUI, nor a terminal capable of showing GUI colors

[jdhao]

I am trying fvim on Windows 10 (version 1803) and noticed weird color issues. I have the following settings related to color in my init.vim:

set termguicolors
colorscheme gruvbox8_hard

For nvim-qt, when I open it, the termguicolors option from init.vim is preserved so that the color is normal. I do not need to set anything related to color in ginit.vim.

Buf for fvim, when I open it, color is apparently wrong. I use set termiguicolors and found that it is reset to notermguicolors. I suppose it is done by fvim? So my colorsheme does not work any more.

To fix this, I have to add:

set termguicolors
colorscheme gruvbox8_hard

to ginit.vim. Is this the intended behavior or a bug? I think this issue is related to https://github.com/yatli/fvim/issues/63.

[jdhao]

I think it is my fault. The termguicolors option is by default off.

In the init.vim file, I have checked if the TERM variable is set to xterm-256color and then set the termguicolors option:

if $TERM == "xterm-256color"
    set termguicolors
endif

Inside neovim GUI front end, the $TERM variable is empty. Nvim-qt may have some sort of settings that set the termguicolors option. But it also occurs to me that since fvim is also a GUI program, maybe it should set termguicolors by default, which makes sense to me.

[yatli]

I have opposite scenarios where termguicolors breaks highlighting. A GUI is not a TUI so I think by definition, termguicolors should be irrelevant, because what it does is to force highlight-guifg and highlight-guibg when the terminal supports ISO-8613-3. With a GUI, that should be supported without explicit settings.

[jdhao]

But without setting termguicolors option explicitly inside ginit.vim, the color is apparently wrong. What is the reason?

[yatli]

I think it's because the colorscheme you're using is broken in notermguicolors?

[jdhao]

That may be the reason since most of the color schemes today presume that we are using a terminal emulator that supports true colors. So if termguicolors option is not set, the color shown will be wrong.

[yatli]

I remember earlier (back when I haven't started the FVim project) that some colorschemes will use aggressive approximations when termguicolors is detected.

[yatli]

On my current colorschemes ( let s:vsim_theme_name = ['falcon', 'gruvbox', 'gruvbox', 'Tomorrow', 'Tomorrow-Night', 'Tomorrow-Night-Blue', 'pencil', 'pencil', 'colorzone', 'PaperColor', 'PaperColor'] ), setting {no,termguicolors} doesn't affect anything

[yatli]

@jdhao could this be related: https://github.com/equalsraf/neovim-qt/issues/219

[jdhao]

I don't think it is related. That issue is about how to detect whether nvim-qt is started.

[yatli]

I've experienced incorrect color settings in falcon because it has has('gui_running') and in fvim it's always 0

So if in a colorscheme file:

if !has('gui_running')
  "do something with termguicolor
endif

[jdhao]

The gruvbox_8 theme I use checks if termguicolors option is set or if has('gui_running') is true, as indicated by the code here. Without setting termguicolors option, the color will be wrong.

[yatli]

Yeah. I'd rather want has('gui_running') to be fixed instead of setting termguicolors. Nevertheless, the current behavior is wrong. FVim reports neither a GUI, nor a terminal capable of showing GUI colors.