Repository navigation
Variable colors are prioritized over hashtable colors for keys in hashtables #182
Description
Keys inside hashtables use the "variable.*" scope over the more specific "meta.hashtable.assignment" scope, this means you can't give keys inside hashtables a custom color that is different from variables.
(Screenshot is from VS code using the "Inspect TM scopes" feature)
Activity
msftrncs commentedon Aug 15, 2019
meta.hashtable.assignmentis less specific. It covers the entire assignment, from the beginning of the key name to the end of the value.metascopes are not intended for use by themes.A better scope for bareword key names is
entity.name.variable.propertyorentity.name.variable.hashkey, as that is inline with what other grammars are using.These are from my PR #156 and my custom theme in VS Code:
There are further things wrong with the hashtable portion of the grammar. A key of a hashtable is actually a non-expandable argument (err operand or identifier actually), which can include unary expressions, and these are not currently correctly handled, as they lose the
assignmentmeta scope. (My PR is currently worse, since its a syntax scoping grammar instead of a keyword scoping grammar, and its an area I am still working on.)PowerShell ISE/PowerShell AST/Tokenizer treats the bareword key name as 'MemberName', which is the equivalent of
property.MartinGC94 commentedon Aug 15, 2019
Isn't this line the regex used for meta.hashtable.assignment?
EditorSyntax/PowerShellSyntax.tmLanguage
Line 1502 in d10ae29
As far as I can tell that only captures up to the "=" part and when I use the inspect TM scopes feature to check out the value part of the statement it seems to confirm this.
It's good to know that meta scopes aren't meant to be used by themes, but I just wanted to be able to change it from my personal settings file, I don't plan on making any public themes myself.
It's good that your PR fixes the hashtable keys, but I'm not a fan of making class methods like:
[convert]::ToBase64String()share the same scope as cmdlets/functions.msftrncs commentedon Aug 16, 2019
That's the line, but it also only works for bareword/indentifier situations, because the regex is syntactically incorrect to capture the quotes, and incorrectly allows identifiers starting with numeric digits.
The
meta.hashtable.assignmentshould technically wrap the entire assignment expression, but that takes a significant more complex rule set to do that yet. Also, additional meta's such asmeta.hashtable.key-expressionand 'meta.hashtable.value-expression` would also be implemented.The intention of meta scopes was to aid tools, such as for region selection, or, for instance,
meta.embeddedallows the editor to offer code completion suggestions in embedded areas where it wouldn't have otherwise been obvious to make them available because they were considered 'not code' (such as inside a string interpolated subexpression"$(cmdlet-here -parameter value)")The complexities with the methods and functions/cmdlets sharing the same scope comes from the fact that PowerShell does too many things. 😄 Themes don't expect to have to handle that many different ideas. One option is to add a higher precedence more specific scope, but I am finding some issue with that, in that Atom doesn't support that yet, that I have heard. I need to prove to Atom that TextMate supports it, but I have some ideas for workarounds involving more complicated rules.
msftrncs commentedon Aug 16, 2019
In PR #156 I did use slightly different scopes between methods and functions,
entity.name.functionandentity.name.function.method.This way a normal theme will catch them both with
entity.name.functionbut a more specialized theme can catch the extramethod. Languages such as C# or JS do not bother with that since all functions are technically methods in those languages.