Syntax Testing: Asserting *Unmatched* Text

[frou]

In Sublime’s syntax testing, is there a way to assert that text is not specially matched by the syntax? For example, bar in what follows.

---

A naive first thought is this. But that doesn’t work since every character in the file matches source.lang, and so that assertion is effectively a no-op:

   foo bar
#  ^^^ keyword.lang
#      ^^^ source.lang

---

Then there’s this:

   foo bar
#  ^^^ keyword.lang
#      ^^^ source.lang -storage -support -entity -keyword -constant -string -comment

…which works, but is verbose and brittle when duplicated in multiple places. For a belt and braces approach there would need to be still more negated selectors in there, too.

---

What if there were something like this?

   foo bar
#  ^^^ keyword.lang
#      ^^^ ONLY source.lang

[kingkeith]

most syntax definitions scope everything they find, what is your use case for ignoring some things in your syntax? color schemes won’t be able to target them etc.

# ^^^ source.lang -storage -support -entity -keyword -constant -string -comment

this also might not work reliably when nested inside another context which has a meta scope etc.

What if there were something like this?

   foo bar
#  ^^^ keyword.lang
#      ^^^ ONLY source.lang

again, it’d be useful to know why this could be useful. Certainly it hasn’t been needed in the syntax definitions that ship with ST, or someone would already have asked for such a feature. Indeed, if it was added, it shouldn’t be specific to syntax tests, but an addition to the scope selector language to allow for checking that a scope selector matches and the end of a given scope stack and has no further scopes.

Key binding only when final entry in scope matches

I want to create a key binding that only fires when the final entry in the scope list is "meta.jsx.js". The keybinding listens to the > key and is used to autocomplete React JSX tags, so when I type <span and then >, I get <span>|</span>. It works really well until I start embedding JSX tags inside dynamically evaluated expressions: <ul> {items.map(item => { if (item.value > 10) { return <li>{item.value}</li>; } return null; })} </ul> In this case, I want the > key t…

[frou]

most syntax definitions scope everything they find, what is your use case for ignoring some things in your syntax? color schemes won’t be able to target them etc.

In addition to stock/third-party syntaxes, I use some private syntaxes that aim for a “light touch” rather than the typical technicolour dreamcoat that wants to classify and consequently highlight virtually everything. (FWIW they’re the classic .tmLanguage format).

I’m not particularly interested in being told I’m Doing-It-Wrong, because these syntaxes work wonderfully in use. If tests are unable to express this then it’s not the end of the world.

[ThomSmith]

Have you considered using “light” color schemes with the standard syntax highlighting?