-
-
Notifications
You must be signed in to change notification settings - Fork 84
Migrate python scope "value" to new scope handler #1877
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
Migrate python scope "value" to new scope handler #1877
Conversation
…arguments migrated to new scope handler
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.
Coming along! Missing
- Domains on assignments
- Leading delimiters on everything except return values (search in scm files for
leading
)
Ok domains on assignments done. Do you have examples for use cases where delimeters matter for the |
It's if you say "chuck value". For example if you wanted to convert a dict to a set by deleting all the values, you could say "chuck every value" and it would clean up the Also, speaking of "every" you'll want to add iteration scopes as well |
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 looks like you've lost a bunch of value captures by making the types more specific here. Search in tree-sitter-python for 'value'
. Eg we lost values within match statement patterns, values in named expressions, etc. I'd be inclined to keep a generic value: (_)
of some sort as that is often what we want
5a93b81
to
094c70e
Compare
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.
094c70e
to
22bf6ea
Compare
ok sorry thought you were sleeping so I force-pushed over my previous commit 😅 |
this PR is good to go now from my perspective; see 22bf6ea |
all told, I made the following changes:
|
The last issue remaining is that the new playground file has some invalid python syntax; see the complaining pre-commit step in CI |
We're also not supporting iteration scope for multi-value return values, eg |
data/playground/python/values.py
Outdated
a = 0 | ||
b = 1 | ||
c = 2 | ||
pass |
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.
wow looks like we have some pretty aggressive "auto-formatting" going on here 😅. cc/ @auscompgeek any idea which formatter is doing this?
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's probably ruff's pyflakes (F) autofixes yeeting the unused variables, then the unused literal expressions?
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.
We could either force playground to be compliant and avoid unused variables or maybe we could have exception for the playground data folder. I prefer the former as it forces us fixing typos and make sure it is valid language since otherwise the cursorless commands won't work in some cases due to typos
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 guess I would prefer a blanket exception for everything in the playground. I have several things in the playground that are not gofmt compliant (but are valid go code ) specifically so that I can experiment to see whether cursorless does the right thing with them.
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 am very much on the fence, but lean slightly towards formatting playground but being liberal with comments to disable auto-formatter / linter where we want. @josharian is it not easy to disable gofmt on a per-line basis?
I don't feel strongly, tho. I could see the benefit to having full freedom in the playground
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.
We could have the pre-commit step check for the actual property we want, namely valid syntax
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 depends in part on how active the formatter is. There is some danger of writing queries that only match when using the same formatter as us, particularly if the formatter is not whitespace only. 🤷🏽
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.
Yeah that's a good point. I think maximal flexibility is not necessarily a bad thing in the playground. Interesting idea to just check for valid syntax. Altho tbh we even might want to violate that in some cases because error tolerance is one of the reasons we like tree-sitter
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'm convinced. See 43939f7. Any objections @auscompgeek @josharian @AndreasArvidsson ?
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.
No sounds resonable
(_) @_.leading.start.endOf | ||
. | ||
right: (_) @value @_.leading.end.startOf | ||
) @_.domain |
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.
fwiw I do think this pattern and the following one (augmented_assignment
) are potentially a compelling use case for #has-type?
predicate, as that would allow them to be merged into one pattern. @AndreasArvidsson @josharian wdyt?
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.
To me it is the same as dictionary vs dictionary_comprehension as discussed in 36c2f4c
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.
Agreed it is quite similar. In that case we managed to avoid duplication by rewriting the pattern another way, but I don't see a way out of it here other than has-type
;; NOTE: in tree-sitter, both "return" and the "1" are children of `return_statement` | ||
;; but "return" is anonymous whereas "1" is named node, so no need to exclude explicitly |
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.
This comment might be overkill. We leverage this kind of assumption all over the place. For example, I'm leveraging this kind of assumption in my leading matchers above, where I rely on the fact that =
is anonymous whereas the name / type before it is not
"visualize value removal" see docs for visualizer, although at this point I think you now know everything in that doc 😄 |
Once this is fixed I think we're good to merge |
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.
Looks good to me!
Checklist
takeValue.yml
from a quick glancevisualize value
command and all thetake value
from this file and they all work fineIf anyone has ideas why the unit tests don't work.
NOTES: