Robin Stocker

`\G` is an interesting one, it will anchor the match at where the current search begins. I wonder if that's necessary for correctness for those syntaxes or if they do...

Hmm so do you know why none of the built-in syntaxes use `\G` at all? Seems strange. I wonder if sregex doesn't support it either and so they avoid it.

fancy-regex 0.4.0 now supports named groups and backrefs, see [changelog](https://github.com/fancy-regex/fancy-regex/blob/main/CHANGELOG.md#040---2020-09-27). `\g` and `\G` are not yet supported.

Nice, thanks for picking this up :)! In the current form, I don't think we should make it a public API. An API with the only output being some printed...

Hehe :). Is it possible to make it return an `Iterator` with results? Then you could just iterate over that and print as the assertions come back.

Makes sense! So escape needs to have precedence over other matches.

@keith-hall So let me get this straight, in this example: ``` embedtesting123escape ``` `embed` matches the embed, that's easy. But then the next match would be that `\w+` matches all...

I tried this example: ``` %YAML 1.2 --- # See http://www.sublimetext.com/docs/3/syntax.html scope: source.nested-embed contexts: main: - match: \( scope: paren.begin embed: a escape: \) escape_captures: 0: paren.end a: - match:...

Just tested, `me` wins (if it's the earlier embed).

Looks like this has been fixed in spring-boot. Can this issue be closed?