This PR is currently compatible with ST 4126+.

Alright, when we're going to ship, we can pre-fix tag stuff.

How do you feel about mixins? This is one area where I find LESS annoying (as a language): any class can be used as a mixin by "calling it". So this is effectively no longer a selector, but a function call.

See: https://lesscss.org/features/#mixins-feature

I am aware of that, but found it of little value to give it a special scope. We'd need to extend the property-or-selector context by another set of 1 or 2 branches to scope (maybe parametrised) mixin definitions and mixin calls. It would be possible - is it worth it?

A mixin definition can also look very much like a normal class #lib.mixin { ... } So how to distinguish normal classes from mixin definitions?

Without definitions not sure if mixin calls are worth the effort then. The primary use case would be to drive goto definition, symbol list, goto reference.

I'd be otherwise fine to highlight them very much the same like selectors in a first step.

The same is with mixins in values. For simplicity reasons I just scoped them meta.selector.less at the moment. The former use of meta.alias is wrong, imho.

A mixin definition can also look very much like a normal class #lib.mixin { ... } So how to distinguish normal classes from mixin definitions?

That's is by definition impossible: any normal classes can be used as a mixin. It's only on the usage of that mixin that you can differentiate. And when a mixin is used it always has the () to "call" it (without the parentheses is deprecated).

Without definitions not sure if mixin calls are worth the effort then

Without a definition you can't do "find usages", so in that sense it adds no value. Is it worth it to perhaps get a different color so you can find your mixins between all the properties and selectors? Well I guess the entire idea behind the syntax in the first place is that it looks the same. So scoping them the same is totally acceptable. For me personally at least :)

Ok, I'm just trying really hard to find holes, that I come up with such niche things is a testament to the quality of your work here. One final thing before I call it a week (I'll have a deeper look at some later time):

In this situation it can't figure out that I'm writing a property, so I don't get the right suggestions. If I add another blank line before the media query, or when I add the property value and a ;, it clears up. Not sure if that's a clear explanation of what happens, but you can see in the screenshot that it's currently expecting a selector instead of a property.

color: could be a property or a custom element tag with : maybe starting a pseudo class. The current approach to distinguish selectors from properties without maintaining huge and never complete lists of predefined tokens is just to try to scope the thing as property: value;. This branch succeeds if a ; ) or } is found directly after the key-value pair.

Otherwise an incomplete selector is assumed.

I'd need to look into whether and how it is possible to improve that edge case.

Well color isn’t a valid element and a custom element needs two words and a dash IIRC, but even then to make something work you’d need to maintain a list… and we already agree that that’s not a good idea.
For me it’s totally acceptable that in some cases the scopes can only be correctly set once the statement is completed. I’ve always found this (selector with pseudo class, or property?) the trickiest bit and never gotten good enough at writing syntaxes to handle it properly. It gets really tricky when a closing semi-colon after a value is not required. That would be an area I would do additional testing.

Other than that, testing with some larger code sets and hunting for edge cases, I defer to you for the scope naming… and it looks really solid already.

HTML also supports "foreign tags", which are any form of valid identifier. A good example are SVG tags. But anything else is fine, too. I guess CSS therefore should be able to highlight them as well. Thus the "custom element needs two words and a dash" rule is unfortunately not sufficient.

I think catching valid CSS at-rules may be something which can easily be added to bailout from property values early, as known at-rules can't be variables and there are not too many.

I aggree that this pseudo-class vs. property issue is very tricky, espececially if no hard coded lists of tokens are to be maintained.

In general CSS's completions try hard to add the semicolon after : automatically so it should normally be of no problem to get value completions.

Scope names are mainly just taken from core CSS. I am not too happy with all of them, but I hesitate to change them because it might break many legacy color schemes.

I am looking into adding some more tests about it.

Support for mixins was added and property vs. selector detection slightly improved. Further improvements are probably possible, but that may take some time for investigation and may be done in a future PR as well.

This PR als vendors ST4149's RegExp syntax to maintain compatibility with ST4107-4126 without adjusting syntax tests etc.

I've got an st4149 branch as well which drops both CSS and RegExp.

Alright, looking good… let’s do it like this:

• You move your fork to the Sublime Text org
• Set up the correct prefixed tags for backwards compatibility
• We can keep this PR open so I have another chance to look at it and maybe give some feedback next week
• Set up a PR on package control to replace the Less entry with the fork

All prepared. Repo moved, you added as maintainer, tags added retarget PR filed.

Package Control PRs at

• Update LESS package wbond/package_control_channel#8749
• Fix Less package wbond/package_control_channel#8751