-
Notifications
You must be signed in to change notification settings - Fork 586
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
[Groovy] use more specific sub-scopes for keywords #4051
base: master
Are you sure you want to change the base?
Conversation
- match: \bas\b | ||
scope: keyword.context.resource.groovy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know as
keyword was topic of discussions multiple times.
Does it make sense to interpret it as kind of keyword.operator.assignment.[as|alias]
?
It is most often used to ...
- import modules under a custom local name (
import foo as bar
) - assign variables another local name (
define foo as bar
, ...)
All of which look like defining alias names for given variables, with just the syntactical difference of assignee being located on the right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is also used in Python to:
3. set the scope of a context manager, syntactic sugar for try, enter context, do work, finally exit context.
To be fair I don't know how Groovy uses it, I'm not familiar enough with it yet, but I was thinking on type 3 in which case I think the context.resource
subscope is more accurate than a simple alias would imply.
I certainly do like your proposal for other cases though. (Except I wonder if the assignee being on the right will be confusing if highlighted the same as other assignments as color schemes would do by default until this specific rule is added...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Python creates over-eager special scopes for all sorts of contexts, which doesn't need to be correct.
My thoughts apply to python and all other syntaxes as well. Context managers instantiate a class and assign it to a variable on the right, which is also some sort of alias for the context manager to refer to.
Actually I have been applying keyword.operator.assignment
to all as
keywords, when tweaking syntaxes as well as scoping in
keyword.operator.iteration
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Original Groovy scopes as
keyword.operator.as
, because it is a coercion operator according to Groovy's language spec. It is a kind of type cast operator.
Hence I'd hesitate to change the keyword.operator
scope.
If a sematic scope is desired maybe
keyword.operator.type.coercion
- or
keyword.operator.type.as
- or
keyword.operator.assignment.type
I've also always struggled with scoping instanceof
keywords, which is also supported by Groovy. They could be scoped keyword.operator.comparison.type
to re-use existing 3rd-level scope or keyword.operator.type.instanceof
.
No description provided.