Carl Morris

I was able to test this grammar on Atom, though only to confirm that VS Code does not behave the same with `\G`. The current version appears to work really...

I finally have IF/ELSEIF/ELSE working the way they should. This was a huge lesson in handling the grammar. The lesson learned is to 'always march forward'. Retreating the grammar rules...

This shot shows the recent commits work towards the statement style scoping, how the same keyword is scoped differently in different contexts.  (Updated image to show labels, do-until loop.)...

I got a solution for the deviation in Atom worked out in https://github.com/PowerShell/EditorSyntax/commit/fd37e90ddd1522c0426f2a6a47716e079554a4c0, dealing with chained statements (if/elseif/else or try/catch/finally or any statement that uses a statement block).

Showing the result of the changes in the last commit: (Edit, 'master' on left, this PR on right, same theme, after the @splat regression was fixed and improved) 

The most recent commit reaches my long desired goal of scoping all the auto/language variables regardless of the syntax used to get them: 

As of today, VS Code 1.35 has been released, and the issues around `\G` have been resolved, so that's great news, but I continue to track differences between VS Code...

Guess I should have been looking at all the tests in the PowerShell repository. Evaluating them for some work I am doing in PowerShell/PowerShell, and I noticed that I am...

I have rebased and squashed, as the commit history at this point is mostly clutter, the entire syntax file has been practically completely overhauled by this PR. There is still...

@RjKGitHub, For 1, its a theme thing. `entity.name.parameter` is not very common, as in the end, most objects becomes `variable`. Defining this scope however in this PR, is what makes...