You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Chained methods and properties on expressions #107
even disregarding the chaining, scoping $variable.anything as an entity.name.function.invocation is very wrong - invocations should never get an entity scope, as they show up in the symbol list. The . should be punctuation.accessor.dot and the identifier afterwards in this case is not a function, just a property, so variable.other.member would suffice. If it were a function, variable.function would be appropriate.
Keith Hall (@keith-hall) you'll find a lot of scoping issues and one of the overarching projects is going to be to review them all. As best as possible I am following https://www.sublimetext.com/docs/3/scope_naming.html; However, I am not a developer so I don't always know what a particular thing in the syntax is fundamentally called and referencing other languages that may also be scoped incorrectly doesn't always help. I have a decent idea but there are gaps.
So far I've fixed some of them, I've left some of them the way they were for the time being, and in at least one instance I set one incorrectly on purpose to meet user expectation across 99% of themes until the actual patterns could be redefined.
One of the issues with the PS syntax file as it stands is that a number of things are defined in pieces with no connections even when directly related. That means you cannot assign a proper parent or meta scope for fallback when themes don't cover one of the more granular scopes. One of my goals is to fix a lot of those issues (variables and function calls are top of the list right now) but some scopes are incorrect for the time being for that reason.
This discussion from 2016 is still open: #8 but it may be worth starting it from scratch at this point.
Activity
keith-hall commentedon May 31, 2018
even disregarding the chaining, scoping
$variable.anythingas anentity.name.function.invocationis very wrong - invocations should never get anentityscope, as they show up in the symbol list. The.should bepunctuation.accessor.dotand the identifier afterwards in this case is not a function, just a property, sovariable.other.memberwould suffice. If it were a function,variable.functionwould be appropriate.omniomi commentedon May 31, 2018
Keith Hall (@keith-hall) you'll find a lot of scoping issues and one of the overarching projects is going to be to review them all. As best as possible I am following https://www.sublimetext.com/docs/3/scope_naming.html; However, I am not a developer so I don't always know what a particular thing in the syntax is fundamentally called and referencing other languages that may also be scoped incorrectly doesn't always help. I have a decent idea but there are gaps.
So far I've fixed some of them, I've left some of them the way they were for the time being, and in at least one instance I set one incorrectly on purpose to meet user expectation across 99% of themes until the actual patterns could be redefined.
One of the issues with the PS syntax file as it stands is that a number of things are defined in pieces with no connections even when directly related. That means you cannot assign a proper parent or meta scope for fallback when themes don't cover one of the more granular scopes. One of my goals is to fix a lot of those issues (variables and function calls are top of the list right now) but some scopes are incorrect for the time being for that reason.
This discussion from 2016 is still open: #8 but it may be worth starting it from scratch at this point.
rescope variable member per PowerShell#107
Scopes (#118)