Color variables not propagating for less syntax

[F1LT3R]

It appears that colors for variables in .less files are not propagated. I am unsure whether vim-css-color does not support this, or whether I am just "doing it wrong".

Please advise.

What I actually see: (MacVim w/ vim-css-color)

What I expect to see: (Sublime w/ ColorHighlighter)

[ap]

It appears that colors for variables in .less files are not propagated.

That’s correct. It would just be too expensive to try.

The plugin already bogs down noticeably on some files (e.g. try opening the plugin’s code under itself and paging down to the hardcoded highlights) but fortunately its impact is bounded by the fact that only the visible portion of the file needs to be parsed per keystroke.

Variable support would require lifting the cap and parsing the entire file on every keystroke, and the parsing would also be more complex.

It’s not necessary to parse the entire file in principle, mind you – it’s just not practical to do better in Vim. If a script could know not just when the buffer has been modified but also which region, and if VimL were expressive and fast enough to write a proper parser, and someone took the effort to write one for Less that had solid error recovery… then the plugin could support variables and be even snappier.

Maybe someday in Neovim?

[F1LT3R]

Hopefully.

Thanks.

[ap]

NP. Another point, btw, is where it gets really problematic, and I don’t know how even a sufficiently powerfully programmable editor would be enough for it: handling @import. Particularly if the imported file is open in another buffer… But it might be reasonable to draw the line at “only variables local to this file, sorry”.

[F1LT3R]

ColorHighlighter fro SublimeText does allow highlighting colors via chained
@import flies. It's pretty useful for larger projects.

I'm looking forward to seeing where Neovim goes.

[Blackskyliner]

For the @import you could, maybe, just cache all @color variables in the imports once, so you would not have the speed impact. No need to refresh after initial parsing. But idk if something like that is (easily) possible in viml.

If a cache is possible I would create a lookup table to know where the color gets defined. Thus, when you are in a file which defines a color, within the line where it gets defined you reparse this line for the color, if it gets changed (or on every keystroke, but only this one) Thus updating the color for all other places. Which would eliminate the "if open in other buffer" as we only have globally stored colors we visited.

Or another approach would be creating a tags like cache file which could be regenerated via command, thus letting the user the choice when to do reparsing of color codes (like on save .less files) Then reading this cache file to know what variable to color how.

But maybe it's out of scope for this project?

[ap]

Maaaaaaaayyyyyyybe. 😊

[shmargum]

just wanna chime in and say that I have made plugin that also handles imports:
https://github.com/shmargum/vim-sass-colors