Decide on scope names for all language constructs

[powershell]

Decide on scope names for all language constructs

[AdjectiveAllison]

Making all of those changes(still don't know how to edit the brackets) makes the following difference.

Current syntax in VSCode

Powershell ISE highlighting

Proposed changes in VScode

As you can see it looks much much better. I have tried it in several different themes and compared with similar results.

[daviwil]

This is a great start! Curious to see what feedback @aeschli might have.

[gravejester]

Yeah, I have started by just filling out the scope names as I have used them. Hopefully we get some feedback from others in the community so we can decide/make changes as we agree on them :)

[vors]

What are good sources for existing scope names?

[gravejester]

Language files for other languages I guess. I tried looking at the built-in for c# that came with Sublime Text. That one was horrible :(

[aeschli]

https://manual.macromates.com/en/language_grammars is the textmate spec. I also found http://www.apeth.com/nonblog/stories/textmatebundle.html useful.

[gravejester]

@aeschli I looked at the TextMate documentation, but it's not always easy to figure out what scope name to use, so it would be good to have a discussion to come to some kind of agreement, regarding PowerShell as a language.

[AdjectiveAllison]

NOTE: This is attempting to colorize powershell syntax correctly and is not attempting to assign the technically correct scopes at all.

These are the main issues that I ran into that I think should be changed:

Variable - $ keyword.other '$' in $variable
Variable - ${..} keyword.other '${' and '}' in ${variable}
Variable - automatic constant.language $_ & $error
Variable - scope storage.modifier.scope 'script' in $script:variable
Variable - name variable.other.readwrite 'variable' in $script:variable

Having all of these as different scopes causes a huge amount of variation between themes that I tested vs powershell ISE. From what I can tell the color of variable.other.readwrite is the color that powershell ISE uses for all of the above variables in every theme that I found. That would mean changing all of the above to variable.other.whatever would be a great way to keep coloring consistent across all themes and editors.

Examples:
$script:muffins $_.muffins ${global:muffins} $false
All of these would be colored correctly with the above changes.

---

Keyword.other.* and keyword.operator.* :

Most of the time these are using the default text color in Powershell ISE(read as every theme I tested). If the editor theme includes keyword.operator or keyword.other specifically it sets the color to the default text color. The issue is when many themes do not have these specified, and you end up with tons of operators being the colors of the keywords, which in ISE this color is mainly just used for keyword.control. This was rather frustrating as I could not find a consistent way to represent these as just the simple text color across multiple themes, is there anything they could be set to that would consistently set them to the default text color? If not this might be something that requires updating themes instead of updating scopes.

Examples: any operator is affected "+ - = == =+ * / | - -match -replace -le ++ etc."
items labeled as other that were not asked to be changed to variable above already "@() () "

---

Things I know are wrong but don't know how to fix yet:

[string] $muffins[0] "[ and ]" I am not exactly sure what brackets are being classified as but they are not working well with themes. They are the same as the operators above where they are always the default text color in ISE, but often cause a ton of color contrast for no reason with the other editors.

[Satak]

Very good demonstration Allieway! My number one reason that I'm not using the VSCode for Powershell projects is the confusing and distracting highlighting. It really should be consistent with ISE.

[omniomi]

We need to reopen this discussion. In my recent changes I followed https://www.sublimetext.com/docs/3/scope_naming.html and compared to some other language syntaxes.

Should we continue here or start fresh?