potentially unwarned failure behavior when INCLUDE cannot be resolved

[msftrncs]

In an INCLUDE in the patterns of a repository item, I was trying to find a way to say 'continue the parent rules here' and even though I have looked through the source and find no such way, my first attempt with $parent worked! I can be pretty sure it works, because this item is used in two different parents which expose different syntaxes, and both work, and also that rules above the parent do not come in to play either. Exactly what I wanted.

But I am not sure it was meant to be. I am pretty sure that $parent causes the code to look for an external grammer, and apparently, when its not found, somehow it slips back in to the parent rule set. This might be because I have not defined any other rules inside this BEGIN-END rule block. (actually pretty sure on this because I tried it somewhere else by changing the last include to try to get all the parent items and I got only the ones already successfully included)

I also checked that anything that does not produce a valid include seems to do the same thing, including "#" and "$", or even "#blah" which doesn't match any repository items.

If I set the INCLUDE to "" then no rules are processed at all inside the block.

Here is the block in question: (revised from https://github.com/mmims/language-batchfile)

		"command_set_group": {
			"patterns": [
				{
					"begin": "\\(",
					"beginCaptures": {
						"0": {
							"name": "punctuation.section.group.begin.batchfile"
						}
					},
					"end": "\\)|$",
					"endCaptures": {
						"0": {
							"name": "punctuation.section.group.end.batchfile"
						}
					},
					"patterns": [
						{
							"include": "$parent"
						}
					]
				}
			]
		}

I would have expected that INCLUDE's that couldn't be found would react the same as "".

I really think textmate could use a $parent include mechanism, as this greatly simplifies blocks. In the case of batchfile, the SET /A command utilizes some operators that can only be used directly if the expression is enclosed in quotes, so two separate block rules would be needed to handle blocks inside quotes and outside quotes because different includes for operators would be needed.

[msftrncs]

I didn't notice this at first, but there is definitely an internal error in the rule engine, as in the above example, when the END finally comes along, the engine pops the current rule stack leaving us at the one before, which is completely wrong. This is because the INCLUDE that could not be resolved did not successfully push on to the stack at the BEGIN. Its not actually this rule's END that is happening, its the parent's END clause that hits (because there is no other way) the closing block mark ) and ends that rule set.

FYI, I am in a position right now where I am only using VS Code, and not a install of the VS Code TextMate repository, so if its generating an error message, I don't see it, nothing showing up in the render1 log.