Skip to content

sub members (properties/methods) of variables appear different behind an array reference #127

Open

Description

@msftrncs

Environment

  • Editor and Version: VS Code: 1.25.1
  • Your primary theme: Dark+ (with corrections for punctuation inside subexpressions inside strings)

Issue Description

Shouldn't both of these appear equivalent? These are all just accessing a property of an object.

$dir.Extension

$dir[0].Extension

($dir).Extension

obviously there could be a complete expression inside the brackets.

image
(image doesn't contain the third example line)

Expected Behavior

I would have expected the properties to both be shown in the same dull yellow, but only the first one is, the others are instead white, the default when no scope match occurs.

Using VS Code's Inspect TM Scopes, the first line, results in 'entity.name.function.invocation.powershell' and 'source.powershell', where as the second only has 'source.powershell'.

Fortunately ${dir}.Extension appears correct, but brings up a different issue.

Activity

  1. Jaykul commented on Aug 16, 2018

    @Jaykul

    This also affects properties and methods chained after method invocations like:

    $Credential.GetNetworkCredential().Password

    image

  2. msftrncs commented on Aug 16, 2018

    @msftrncs
    ContributorAuthor

    I think I found a work-around for this:

    Change the 'end' matches for both 'interpolation' and 'interpolatedStringContent' to

    			"end": "(\\))((?:\\.(?:\\p{L}|\\d|_)+)*\\b)?",
    			"endCaptures": {
    				"1": {
    					"name": "punctuation.section.group.end.powershell"
    				},
    				"2": {
    					"name": "variable.other.member.powershell"
    				}
    
  3. msftrncs commented on Aug 16, 2018

    @msftrncs
    ContributorAuthor

    also, this for both 'attribute' and 'type':

    			"end": "(\\])((?:\\.(?:\\p{L}|\\d|_)+)*\\b)?",
    			"endCaptures": {
    				"1": {
    					"name": "punctuation.section.bracket.end.powershell"
    				},
    				"2": {
    					"name": "variable.other.member.powershell"
    				}
    			},
    
  4. msftrncs commented on Aug 16, 2018

    @msftrncs
    ContributorAuthor

    Looks like I went too far with 'iterpolation' … it gets used by string expansion subexpressions, which causes problems with subexpressions in strings. This would need to get separated.

  5. omniomi commented on Aug 16, 2018

    @omniomi
    Contributor

    Carl Morris (@msftrncs) I am planning to completely overhaul how variables are captured from the ground up (#137) so I don't want to spend a lot of time picking away at the existing captures because the root of the problem is the whole methodology; However, if you'd be willing to prepare a PR in the mean time since it could take me a while we'd be happy to review it/merge it.

    There are instructions in the readme on how to build and test the grammars or you can always just submit a PR marked as a WIP and let the CI scripts run the tests for you.

  6. msftrncs commented on Aug 16, 2018

    @msftrncs
    ContributorAuthor

    Nick James (@omniomi), I'll try to work that up (relatively new to concept of Git). I can completely understand the goal of overhauling parts, as it becomes evident trying to trace down all the nearly identical behaviors in different parts, dealing with repository object naming logic, etc.... In the meantime, I think I have worked off the major annoyances I have found. It will definitely take me a bit to sort out all the changes I have been making.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions