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

Add more detailed textmate scopes for types in python grammar #174206

Closed
Redoubts opened this issue Feb 13, 2023 · 3 comments
Closed

Add more detailed textmate scopes for types in python grammar #174206

Redoubts opened this issue Feb 13, 2023 · 3 comments
Assignees

Comments

@Redoubts
Copy link

Redoubts commented Feb 13, 2023

I think the python grammar should have more support for types, both type annotations, and type comments (or not since that's worth less now). Ironically there's more info for type comments than annotations currently.

Currently there's the type comment:

                        |- comment.typehint.punctuation.notation.python
# type: (Iterable[str]) -> Optional[Class]
|  |      |                           |- comment.typehint.variable.notation.python
|  |      |- comment.typehint.type.notation.python
|  |- comment.typehint.directive.notation.python
|
|- meta.typehint.comment.python comment.line.number-sign.python source.python (applies to everything)

Which I think is mostly there, but I wish the arrow was part of the directive.notation, just like the colon is in type:.

For the type ignore:

# type: ignore[attr-defined]
    |     |     |  |- (the dash is no longer a comment.typehint.* !)
    |     |     |- comment.typehint.variable.notation.python
    |     |- comment.typehint.variable.notation.python
    |- comment.typehint.directive.notation.python

I think type: ignore should all be a directive. The argument inside should maybe be a new thing? Variable is kinda ok, but I think variable.error? or something additional suggesting it's an error argument would be nice. I do think it's weird the - in attr-defined loses the comment.typehint scope entirely, since it's all one label. If this were # type: ignore[attr-defined,call-arg] (two labels sep by comma), the comma is at least still a comment.typehint.punctuation.notation.python

For full type annotations:

                                                  |- constant.language.python
                                                  |    |- punctuation.separator.annotation.result.python
async def x(arg1: Iterable[Class], arg2: Class | None) -> Class:
             |      |        |             |                |- no more annotations!
             |      |        |             |- no more annotations!
             |      |        |- meta.item-access.arguments.python meta.item-access.python
             |      |- meta.indexed-name.python meta.item-access.python
             |- variable.parameter.function.language.python 
  (meta.function.parameters.python meta.function.python source.python) applies everywhere

There's really not much going on here tagging these as type related, and I wish there were. Things like Iterable[Class] and Class | None should have a type annotation scope of some kind, and same with the return type. I think -> has a good scope name, but the union seperator should also have a relevant scope that's more than just keyword.operator.bitwise.python

Ideally there should be more to go on for type annotations than type comments in python.

@Redoubts
Copy link
Author

I think this is controlled in https://github.com/microsoft/vscode/blob/main/extensions/python/syntaxes/MagicPython.tmLanguage.json, but I'm not fully sure.

@RedCMD
Copy link
Contributor

RedCMD commented Feb 13, 2023

@Redoubts
Copy link
Author

@Redoubts Redoubts closed this as not planned Won't fix, can't repro, duplicate, stale Feb 13, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Mar 30, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants