Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

keith-hall
Copy link
Collaborator

No description provided.

Comment on lines +200 to +201
- match: \bas\b
scope: keyword.context.resource.groovy
Copy link
Collaborator

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

  1. import modules under a custom local name (import foo as bar)
  2. 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.

Copy link
Collaborator Author

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

Copy link
Collaborator

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.

Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants