Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upTokenize *args and **kwargs the same as other parameters (tree-sitter) #303
Conversation
|
Cool! Thanks, @caleb531. I also compared the syntax highlighting in this pull request to the syntax highlighting that the old TextMate grammar provides, and confirmed that this pull request brings the Tree-sitter syntax highlighting up to par with the TextMate syntax highlighting for *args and **kwargs: TextMate
Tree-sitter before this PR
Tree-sitter after this PR
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
caleb531 commentedMay 12, 2019
Requirements
Description of the Change
Back in #297, I added highlighting for formal function parameters to the Python tree-sitter grammar. This PR follows up on that work with two additional fixes for splat parameters such as
*argsand**kwargs.Alternate Designs
I could've chosen more-generic or more-specific selectors to tokenize these nodes, depending on how broad these changes are desired to be. But to avoid any potential breakages, I aimed to keep these changes narrow in scope.
Before:
After:
Benefits
More consistent syntax highlighting for tree-sitter-tokenized Python files, continuing in the spirit of #297
Possible Drawbacks
I don't think there are any, as I tried to make my changes focused enough to avoid breaking anything. But if there's anything else I could consider in terms of the impact on Python syntax, please let me know!
Applicable Issues
#297 (already merged by @nathansobo)