Unwanted coloring in lua files about vim-css-color

[ap]

Oh fer cryin’ out loud.

The Lua syntax uses contains=ALLBUT,... to create syntax groups that create every match/keyword that’s not explicitly excluded. And obviously the css-color matches/keywords aren’t excluded because the Lua syntax doesn’t know anything about them.

This ALLBUT thing is a pretty terrible idea. 😦 You can’t have multiple syntaxes cooperating peacefully within the same buffer. E.g. if you could embed Lua inside HTML, the HTML syntax couldn’t load the Lua syntax to highlight Lua bits the way it loads the CSS syntax to highlight CSS bits inside style attributes and tags – because the Lua syntax would take over the whole buffer. And this ALLBUT business isn’t even necessary given containedin (which is what css-color uses…). Argh.

And Vim also has CONTAINED and TOP faux group names that do the same as ALL/ALLBUT, just slightly more selectively. They’re all terrible ideas for the same reason.

I should file a bug on the Lua syntax. And then grep for other syntaxes that do this, and file bugs against them too. And then post to the Vim list and try to convince Bram to take a patch to the documentation that points out the problems with these things.

In the meantime I guess I have to add a hack to the Lua syntax that adds colorableGroup to every ALLBUT defined by the Lua syntax.

Sigh.

[ap]

Wonderful… ALLBUT and friends can only exempt individual groups (e.g. BGffd700), not entire clusters (@colorableGroup).

So every time the plugin recognises a new colour name, it would have to hack the syntax again, to add the new match group to all the ALLBUTs. Which might be noticeably janky, and would require adding a code path that would slow down the plugin in every filetype. No can do.

I guess until such time as the Lua syntax works sensibly, I I have to drop Lua support. 😦

[ap]

I’ve just pushed a commit that drops the Lua support. You should be good to go now.