Example of working as expected
Input is on the left, output is on the right.
The "end" pattern is referencing the 2nd group created in "begin" (the EOF)

What (intentional) failure looks like (non-issue)
A bad pattern causes this kind of behavior:
(note: yellow is the theme's color for entity.shell, which is the included pattern)

What is broken
\k<2> should be equivlent to \2 and in other places it does behave equivlently
However, instead of failing normally (e.g. all-yellow) it seems to trigger undefined behavior:
(Note: \2 is not a viable workaround when group numbers are ≥10)

Here's the code for the problematic pattern.
This is for VS Code 1.72.2, on Mac M1
{
"begin": "(<<)\\s*+\\s*+((?<!\\w)[a-zA-Z_][a-zA-Z_0-9]*(?!\\w))(?=\\s|;|&|<|\"|')",
"end": "\\2",
"beginCaptures": {
"1": {
"name": "keyword.operator.heredoc.shell"
},
"2": {
"name": "string.delimiter.shell"
}
},
"endCaptures": {},
"name": "string.unquoted.heredoc.no-indent.shell",
"patterns": [
{
"match": ".+",
"name": "entity.shell"
}
]
}
Example of working as expected
Input is on the left, output is on the right.

The "end" pattern is referencing the 2nd group created in "begin" (the EOF)
What (intentional) failure looks like (non-issue)
A bad pattern causes this kind of behavior:

(note: yellow is the theme's color for
entity.shell, which is the included pattern)What is broken
\k<2>should be equivlent to\2and in other places it does behave equivlentlyHowever, instead of failing normally (e.g. all-yellow) it seems to trigger undefined behavior:
(Note:
\2is not a viable workaround when group numbers are ≥10)Here's the code for the problematic pattern.
This is for VS Code 1.72.2, on Mac M1
{ "begin": "(<<)\\s*+\\s*+((?<!\\w)[a-zA-Z_][a-zA-Z_0-9]*(?!\\w))(?=\\s|;|&|<|\"|')", "end": "\\2", "beginCaptures": { "1": { "name": "keyword.operator.heredoc.shell" }, "2": { "name": "string.delimiter.shell" } }, "endCaptures": {}, "name": "string.unquoted.heredoc.no-indent.shell", "patterns": [ { "match": ".+", "name": "entity.shell" } ] }