Fix a bug in the grammar of @supports

[hediyi]

in the commit message of 698e3c4

[winstliu]

\\b(not|or|and)\\b

[hediyi]

is \\b(not\\b|or\\b|and\\b) ok?

[winstliu]

Yes, why?

[hediyi]

Performance. 😆

[winstliu]

Please rebase to get rid of the ellipse commit.

[hediyi]

Anything else?

[winstliu]

Just to increase my understanding of things: how does this fix the referenced issue? Is it because #properties puts things in the correct order, whereas the current manual order did it wrong?

[hediyi]

First, the problem is actually I overlooked the fact that some word can be both a property and a value in CSS—flex in this case (can't say there won't be more in the future)—in the old way, it will always be tokenized as either a property or value, depending on, #property_names and #property_values, which comes first in the grammar.

{
  'include': '#constant_property_value'
}
{
  'include': '#property_names'
}
{
  'include': '#property_values'
}

In the old way, at first, there were just #property_names and #property_values (flex always tokenized as property name), I patched it by placing a #constant_property_value at the beginning (now always value) to make the test pass. But as you can see in the new specs, this didn't really solve the problem.

The fix mainly comes from that #properties wraps a layer around #property_values which specifies when exactly a token can be a value (begin and end):

{
  'begin': '(:)\\s*(?!(\\s*{))'
  …
  'end': '\\s*(;|(?=}|\\)))'
  …
  'contentName': 'meta.property-value.scss'
  'patterns': [
    …
    {
      'include': '#property_values'
    }
  ]
}

[winstliu]

Ok, that's what I was thinking, but just wanted to double-check. Thanks.

[winstliu]

(Wrong button 🙈)

[hediyi]

No problem 😆