Skip to content

Chained methods and properties on expressions #107

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
vors opened this issue May 26, 2018 · 2 comments
Open

Chained methods and properties on expressions #107

vors opened this issue May 26, 2018 · 2 comments

Comments

@vors
Copy link
Contributor

vors commented May 26, 2018

Moving from SublimeText/PowerShell#68
And SublimeText/PowerShell#77

Environment

  • Editor and Version (VS Code, Atom, Sublime): Sublime
  • Your primary theme: Default

Issue Description

There is inconsistency in the chained methods:

$users.Split(",").Trim()

Split and Trim get 2 different regions.

Same applies for

$foo.bar

vs

($foo).bar

Screenshots

image

Expected Behavior

  • Trim() and Split() should be the same region type
  • .bar in first and second case should be the same region type

Code Samples

$users.Split(",").Trim()

$foo.bar
($foo).bar
@keith-hall
Copy link
Contributor

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.

@omniomi
Copy link
Contributor

omniomi commented May 31, 2018

@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.

omniomi added a commit to omniomi/EditorSyntax that referenced this issue Jun 9, 2018
@omniomi omniomi mentioned this issue Jun 9, 2018
TylerLeonhardt pushed a commit that referenced this issue Jun 11, 2018
* rescope statement separator per #114

* rescope everything after --% #113

* rescope string punctuation per #110

* include sigil in variable scope per #23

* rescope variable member per #107

* rescope variable sigil per #23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants