Syntax highlighting for block scalars incorrectly highlights invalid strings

[heaths]

According to http://yaml.org/spec/1.2/spec.html#id2795688, any string therein should be literal and cannot be escaped; however, VSCode shows all strings having errors or otherwise incorrect. These cannot be quoted, or the quotes will - as spec'd - end up in the VSTS tasks (see screenshot).

This is generated from the following YAML (which GitHub highlights correctly):

testAssemblyVer2: |
  **\$(BuildConfiguration)\*mocks*.dll
  **\$(BuildConfiguration)\*test*.dll
  **\$(BuildConfiguration)\Win32\*test*.dll
  !**\obj\**

Folded blocks have a similar problem:

packagesToPush: >
  $(Build.SourcesDirectory)\**\*.nupkg;
  !**\*.symbols.nupkg;
  !**\packages\**\*.nupkg;

...yields:

Seems any text within literal or folded blocks should be treated as plain strings,

Copied from original VSCode issue 54219.

[heaths]

Using the TM inspector in VSCode, it seems the problem is the end matching immediately, leaving the remaining lines to be detected as variables and metas - which would be invalid as unquoted. I just started exploring the TM grammar and it seems a way to solve this requires knowing how much space begin the entire block and ending when exactly that much space before non-whitespace is matched again. Such a regex would be the new end. Is this possible? Perhaps by using named capture groups?

[infininight]

I have tracked down the cause of this but it is not currently possible to fix due to a limitation in the grammar parser. We are investigating if/how this can be addressed in the parser.

[Tronic]

It is possible to use captured groups in while/end regex: (tested in VSCode)

"begin": "^(\\s*)(\\w*): |$",
"while": "^\\1\\s+",

I see that TextMate and Github highlighter already have a working version for YAML but VSCode doesn't. This might also be of interest to anyone else wishing to implement string literals by indentation...

[heaths]

@aeschli, would it be possible (I could even do it if you like) to use this workaround rather than wait for TextMate to otherwise fix this? Any way to denote that the generated files require a tweak or two like this?

[aeschli]

@heaths As a first step I suggest to make a PR against this repo.

[Tronic]

This is already fixed in TextMate (tested in version 2.0-rc.23). Github uses https://github.com/atom/language-yaml/blob/master/grammars/yaml.cson which also works. I don't know if VSCode supports the CSON format but it should be trivially convertible to VSCode-compatible JSON.

[heaths]

@aeschli, that being the case (this is already fixed in TextMate as @Tronic said), you pulling and transforming source should work now for VSCode, correct?

[aeschli]

Please create an issue in the vscode repo so we can find out why this works in TextMate but not in VSCode and whether VSCode should switch to a different grammar.

[heaths]

Will do, but I don't think anyone is saying this wouldn't work in VSCode - only that someone found a workaround and that this was fixed in TextMate recentlyish.

[dfenerski]

uhhh seems still open? "unexpected scalar at node end yaml vscode" led me to this issue