Fail to colorize named colors in CSS

[msva]

Hi!

I found strange behaviour:

if I open test CSS file with enabled autocolorizing (either way, through g: variable in vimrc, or through calling ColorHighlight in au), or even call ColorHighlight manually, I get the following:
hex-colors are colored, darkred is colored (dunno why), but named colors is not. But if I open multiple files altogether (in separate buffers), then all works (almost) as intended:

Can you advice a way why the plugin can work in that way, and how to avoid that behaviour and force it to work as intended? :)

P.S. by the time of making second screenshot I aliased "black" to "#444444", since normally I using swapped fg/bg and black (as other dark (darker than #262626) colors) is invisible on dark terminal, that is why "black" rendered as gray, and possibly that is why it also makes font on bright colors to be gray, so it is not a bug, if any :)

[chrisbra]

works for me. Can you show me the output of :for i in getmatches() | echo i |endfor

[msva]

when it is only that CSS-file opened — it is notings (getmatches() returns empty array ([])).

But with "workaround" (when multiple files opened and it isrendered as intended) the result is:

{'group': 'Color_000000_D1D24C', 'pattern': 'rgb(209,210,76)', 'priority': -2, 
'id': 4}
{'group': 'Color_FFFFFF_000000', 'pattern': '#000000\%(\>\|[-_]\)\@=', 
'priority': -2, 'id': 5}
{'group': 'Color_FFFFFF_202020', 'pattern': '#202020\%(\>\|[-_]\)\@=', 
'priority': -2, 'id': 6}
{'group': 'Color_FFFFFF_222222', 'pattern': '#222222\%(\>\|[-_]\)\@=', 
'priority': -2, 'id': 7}
{'group': 'Color_FFFFFF_242424', 'pattern': '#242424\%(\>\|[-_]\)\@=', 
'priority': -2, 'id': 8}
{'group': 'Color_FFFFFF_262626', 'pattern': '#262626\%(\>\|[-_]\)\@=', 
'priority': -2, 'id': 9}
{'group': 'Color_FFFFFF_282828', 'pattern': '#282828\%(\>\|[-_]\)\@=', 
'priority': -2, 'id': 10}
{'group': 'Color_FFFFFF_303030', 'pattern': '#303030\%(\>\|[-_]\)\@=', 
'priority': -2, 'id': 11}
{'group': 'Color_000000_e2571e', 'pattern': '#e2571e\%(\>\|[-_]\)\@=', 
'priority': -2, 'id': 12}
{'group': 'Color_000000_ec883a', 'pattern': '#ec883a\%(\>\|[-_]\)\@=', 
'priority': -2, 'id': 13}
{'group': 'Color_FFFFFF_8B0000', 'pattern': '-\@<!\<darkred\>\c-\@!', 
'priority': -2, 'id': 14}
{'group': 'Color_000000_FFFF00', 'pattern': '-\@<!\<yellow\>\c-\@!', 
'priority': -2, 'id': 15}
{'group': 'Color_FFFFFF_444444', 'pattern': '-\@<!\<black\>\c-\@!', 
'priority': -2, 'id': 16}
{'group': 'Color_FFFFFF_FF0000', 'pattern': '-\@<!\<red\>\c-\@!', 'priority': 
-2, 'id': 17}
{'group': 'Color_FFFFFF_0000FF', 'pattern': '-\@<!\<blue\>\c-\@!', 'priority': 
-2, 'id': 18}
{'group': 'Color_000000_F0F8FF', 'pattern': '-\@<!\<aliceblue\>\c-\@!', 
'priority': -2, 'id': 19}

[chrisbra]

interesting. I wonder why :ColorHightlight would not highlight it. Do you have another colorizer plugin installed?

[msva]

Nope, I don't. Only additions to default vim that I have is: 1) system-wide thirdparty syntax-highlight definitions from system package manager

2) neocomplete.vim

3) Colorizer (I mean, this one)

4) molokai color theme

5) gnupg plugin

6) some custom vimscripting around statusline, tabline, autocmds, keymappings and so on.

That's all. I don't even use any of that over9000 plugin engines.

[msva]

by the way, even with "workaround" of opening multiple files, issiue anyway triggers when Colorizer re-applies colorizing for any reason (will it be change/addition of some color, or manual call to :ColorHighlight, or even sourcing vimrc).

Moreover, workaround itself have effect only if that css file will appear in inactive buffer.

[msva]

oh! I found it! This behaviour is only appears if g:colorizer_syntax is 1!

[chrisbra]

On Sa, 11 Feb 2017, Vadim A. Misbakh-Soloviov wrote:

oh! I found it! This behaviour is only appears if g:colorizer_syntax is 1!

great you found it. Pushed a fix. Thanks!

Best, Christian -- Die Nacht ist so zu Träumen eingerichtet, daß man auch wachend in Träume gerückt wird; man wird von ihr traumtrunken. -- Jean Paul

[msva]

Yeah, it is fixed initial issue, but it is still some artefacts: Check a difference of this (g:colorizer_syntax is unset): with that (g:colorizer_syntax=1):

1) black is still uncolored in syntax mode. 2) in match mode colors are bold, while in syntax they're regular.

I guess, all of this is not as intended too ;)

P.S. 3) #000000 in syntax mode is rendered totally black, while in match mode it is gray. And now I unsure what is intended behaviour, and what is artefact ;) 4) I have undefined custom colors in both cases, so the fact that 000000 is rendered gray, I guess, is "just as planned". While the fact that # is still black is not, I guess (I'll post about it in #51).

EDIT: P.P.S. Sorry, initially I misplaced screenshots in this comment. Now I fixed that.

[msva]

Anyway I like the current behaviour of match mode (even rendering colors in bold), so, I'll use it. So, previous comment is mostly just for you info :)

[chrisbra]

I can not confirm that: The only problem is, that black is hidden behind the cssfontattr syntax group. I don't want to clear that syntax group, as it will probably break other things. So I would suggest going with matchmode (which is the default and should always work, because it is more flexible and one can better adjust priorities). For why it is being bold for you, I cannot tell. I certainly do not mess with bold attributes.

[msva]

Ok, I anyway will use match mode, so ok.