Compatibility problem with `set cursorline`

[mwcz]

First, love the plugin! It even worked out of the box with .less files. That may be because I have the vim-less plugin. If it could be made to work with the .less color functions like lighten(color,percentage), my palette.less file would be gorgeous. Either way, it's pretty awesome.

Onto the (fairly minor) problem. I use the set cursorline option which highlights the line the cursor is on.

Cursor on first line:

Cursor on same line as a color:

I skimmed through the plugin but I don't know enough vimscript to fix it straightaway. When a color is on the cursor's current line, it should either colorize the fg and bg, or neither. Right now, it's colorizing the fg but not the bg.

The colorscheme in the screenshots is zenburn. Let me know if I can provide any other info.

[ap]

That is indeed a bug. I’ll take a look.

[ap]

Ah foo.

What happens is that after all of the highlight attributes have been computed, the CursorLine attributes are added on top. And in most colour schemes, CursorLine is defined to override guibg and/or ctermbg. Unfortunately those are what vim-css-color uses for the CSS colour – plus it sets the foreground to either white or black. When the background colour gets overriden by CursorLine, then only the foreground colour from vim-css-color is left, combined with the CursorLine background colour, and the result is what’s on your screenshot.

I’m afraid that given how cursorline works, I cannot see any way to make something smarter happen. You’re out of luck.

Sorry.

[ap]

I’ve added a note to this effect in 9802f41.

I am closing this ticket as CANTFIX for now; if you or any future reader has a bright idea for how to circumvent the problem, I’m all ears.

[mwcz]

Drat, I was afraid of that. Is it possible to use getline to figure out what line the cursor is on and not apply any colors to that line?

[ap]

I’m not sure. If anything can be done, it will require the script to work completely differently.

The way it currently works is that as you move around the file, the script watches the current line and adds syntax rules that will cause the CSS colours in that line to get highlighted – but note that a syntax rule applies across the entire file. The script does not perform the highlighting itself – once the highlight rule is added, the matter is out of its hands and Vim’s highlight engine takes over. The reason the script watches the file at all is that otherwise it would have to add roughly 24 million highlight rules all at once – one highlight for each possible RGB colour.

You can watch this happen in realtime if you comment out this bit at the bottom of after/syntax/css.vim:

let view = winsaveview()
%call s:PreviewCSSColorInLine()
call winrestview(view)

What this bit does is run over the whole file when you load it, and add all the RGB colours that are already mentioned in the file. If you comment it out and edit a CSS file, you’ll see that the colours in the file are all un-highlighted at first (except the W3C-predefined colours like red, white etc), but as soon as you move the cursor to a line, the colours in that line become highlighted everywhere in the file – because vim-css-color just added syntax rules for those colours, and Vim’s highlight engine immediately applies the rules to the whole file. The reason you don’t notice this normally is those commented-out lines, which make it impossible for un-highlighted colours to exist in the file anywhere else than the line you are currently editing.

I don’t know how to address the CursorLine highlight within this architecture. 😦

Basically this plugin is a huge hack – one that works very well, but a hack nonetheless, due to the fact that Vim does not provide any way to run code to compute attributes from a syntax rule match. If it did, then higlighting CSS colours would be much easier than these autocommand contortions (or adding 24 million syntax rules), and within the same code you could also do things conditionally based on cursorline.

But, as I said, if anyone who reads this has a spark of inspiration, do tell me.

[mwcz]

For posterity, I'll note that cursorcolumn has the same effect as cursorline. Not surprising.

Thanks for looking into it so thoroughly and for the informative explanation. Any bug with a workaround of "move the cursor down one line" is an easy bug to deal with. I'll continue carefree use of vim-css-color. 👍

[ap]

Someone mentioned in the tickets on skammer’s original fork that lilydjwg/colorizer works even on a cursorline. I don’t know if that’s true, but I’ll have to take a look at what it does, and see if I can steal the idea.

[mwcz]

Nice!

[ap]

I’m reopening this so I won’t forget to take a look at least eventually.

[gko]

Hi everyone, I ended up merging this plugin and colorizer, so that I can avoid this bug but keep hsl(a) and named colors: coloresque
Don't forget to put 'star' on repo =)

[chrisbra]

Try chrisbra/color_highlight That is an improved version of lilydjwg/colorizer

[ap]

Belated Xmas present for @mwcz: I just pushed a fix for this. 😄