truecolor terminals and termguicolors about vim-css-color HOT 5 OPEN

Hi, sorry I didn’t get around to your bug report. Thank you for the PR. I do have some unreleased changes which include a fix (at least a partial one) for that… but I never finished and shipped them. To make amends I was going to just accept the PR even if it doesn’t look entirely as I’d prefer, so at least some fix is shipped, and leave my own preferences for later when I come back to it.

But the more I look at the patch, the more questions I have unfortunately. 🙁

You are obviously right about the t_Co check.

But about &termguicolors I’m not so sure. Is it possible for a terminal to advertise only (say) 16 colors yet still support full RGB? That is to say, is it even necessary to check that specifically, or is it just redundant with the t_Co check?

Also, making the loading of the plugin conditional on the current value of a variable seems like a problem. If the user currently has termguicolors reset but the terminal has RGB support, shouldn’t the user be able to set termguicolors and have CSS Color start working – without requiring a restart of Vim? (Well, by that token, the t_Co check is a problem too. Hmm.)

I don’t feel confident that I have the whole picture reasoned out yet.

As for the css_color#disabled() part of the patch – a predicate like that makes total sense of course, but it needs a different name because there are already css_color#enable() and css_color#disable() functions which do something totally different. Also v:true and v:false were not available in Vim 7.0, which this plugin still supports, so it’d have to be just 0 and 1. Anyway, this seems more like a job for a variable, similar to the customary g:loaded_someplugin variable many plugins have, though loaded is not the right term here either. I’ll have to think about that one too.

from vim-css-color.