TERM=linux : wrong t_Co during startup

[elcarlosIII]

• nvim --version: v0.1.6-309-g90bf31c
• $TERM: linux

Behaviour

Colorscheme does not load correctly in framebuffer console (eg. the wildmenu is black on black).
After reloading default colorscheme manually, colors seem to be "normal".

Steps to reproduce using nvim -u NORC

nvim -u NORC

[justinmk]

After reloading default colorscheme manually, colors seem to be "normal".

That's a colorscheme bug. Most likely a misplaced :set background=.... Or maybe the placement of colorscheme call in your init.vim needs to be adjusted.

[elcarlosIII]

Not even the default colorscheme does load correctly, when starting neovim.

[mhinz]

Can you reproduce this with nvim -u NONE +'syntax on'? Does it only happen in the framebuffer console?

[elcarlosIII]

Yes, the default colorscheme does not load properly when I invoke neovim using nvim -u NONE +'syntax on'. And yes it seems to happen in the framebuffer console only.

[mhinz]

Does the same happen with Vim?

[justinmk]

How would one reproduce this in a VM? With TERM=linux things work fine for me. Maybe a terminfo issue?

[elcarlosIII]

Vim does not have this problem.
I do not know how to reproduce this in a VM, but I happens on a recently updated Arch Live CD, when using one of the ttys (no X).

[stev47]

I can confirm that the nvim wildmenu uses black text for the selected entry on both tty and when started with TERM=linux nvim in a virtual terminal (urxvt in my case). A black background makes it obviously unreadable. There may also be some other wrong colors.

[justinmk]

fab6214 explains what's going on here: "mis-reporting 't_Co' during startup" is why colorscheme is wrong before startup.

Fixing this might be a bit fiddly but it should be straightforward, if anyone wants to spend the time. Help would be welcome.

[knghtbrd]

I just stumbled across this issue and think I may be experiencing the same problem. I have a colorscheme written for GUI and 256 color terminals. It does NOT support 8/16 color terminals. In vim, this is simple:

if &t_Co < 256 && !has("gui_running")
	set bg=dark
	colorscheme default
else
	colorscheme xoria256
endif

NeoVim always concludes that we have 256 colors and/or GUI, even if we don't. There is simply no way to test for an 8 or 16 color terminal in NeoVim, nor to tell NeoVim not to replace (mostly) functional highlighting (default visual-mode selections can/do result in light gray on light gray unreadable text) with less highlighting than the average 1970s teletype.

Perhaps its a documentation issue if how this is done has changed, or a feature regression from standard vim. I'm not even sure it's the issue you're seeing here, but I'll bet it's related. (Interestingly enough, the xoria256 theme looks great under tmux on the Linux terminal. If it did that without tmux running, I wouldn't be using the above block. I would still want to detect the low-color case to change a few defaults, though.)

[knghtbrd]

... Yup, it's related. And I can see how fixing it will be not trivial. Fortunately there are workarounds for the time being.

[justinmk]

#6673 should fix this for linux 4.8, if not older.

[knghtbrd]

I waited for Debian to update as their version was rather old even in sid due to the way their release cycle works. Currently it has 0.2.0, and I find that the Linux console remains monochrome.

My init.vim now always uses a 256 color theme because neovim ripped out the ability to detect when your terminal didn't support that. If I run tmux at the console, I get 16 color approximations, but with the plain console and TERM=linux, if you use any but the base 16 VGA colors, you get nothing but silent failure.

Still running Linux 4.9 here, but this is supposed to work with 4.8. Unless I'm missing something, this bug appears to still exist. Obviously the Linux framebuffer console has only 8 or 16 VGA colors. Alas kmscon is dead and fbterm was more hassle than it was worth. This was fine--you just couldn't have a fancy high-color theme in vim. But now you cannot detect that you need a low color theme, and high color themes simply don't work.

[justinmk]

because neovim ripped out the ability to detect when your terminal didn't support that. If I run tmux at the console, I get 16 color approximations, but with the plain console and TERM=linux,

Nvim did not rip out the ability to check $TERM. Can't you check that?

[justinmk]

Resolution/Summary

• see TERM=linux : wrong t_Co during startup #5538 (comment)
• Since Nvim 0.3.2 'background' defaults to "dark", which should accidentally help with this particular report.
• TUI: detect background color #9509 adds background-color detection, although that's probably not supported by Linux VT.

Generally, Nvim startup is not blocked on waiting for the UI, including the TUI. So depending on a particular value of &t_Co during startup isn't going to work. Check $TERM or some other environment clue.

---

Locked to keep the summary visible. You can always chat or open a ticket if you have new information/topics to discuss.