Skip to content

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

Merged
merged 13 commits into from
Sep 10, 2023

Conversation

saidelike
Copy link
Collaborator

Checklist

  • I have executed the existing tests but they seem to fail for whatever reason. Not sure why (e.g. takeValue.yml from a quick glance
  • I have tested the visualize value command and all the take value from this file and they all work fine

image

If anyone has ideas why the unit tests don't work.

NOTES:

  • I haven't included the assignment symbols like ".", "=", "/=" as I don't think they are needed when using the tree-sitter but let me know if you think otherwise.
  • the "return" in the "return_statement" is something that was ignored too as not relevant anymore afaict

@saidelike saidelike requested a review from pokey as a code owner September 8, 2023 15:00
@saidelike
Copy link
Collaborator Author

And this is temporarily disabling the assignment values to see the domain of dictionary values:

image

Copy link
Member

@pokey pokey left a 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)

@saidelike
Copy link
Collaborator Author

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 value scope? I understand the , in the arg scope case, but I don't see it for value...

@pokey
Copy link
Member

pokey commented Sep 8, 2023

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 :. Not totally clear how useful it is for assignments, but we support it today so I'd be inclined to preserve that behaviour. That's what the long list of assignment operators is doing in the original code (eg =, +=, etc)

Also, speaking of "every" you'll want to add iteration scopes as well

@auscompgeek auscompgeek added lang-python Issues related to Python programming language support scope-migration Migrating scopes to next-gen scope implementation labels Sep 9, 2023
@saidelike
Copy link
Collaborator Author

Added value iteration scopes:

visualize value:

image

visualize value iteration:
image

Copy link
Member

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

@pokey pokey force-pushed the migrate-python-scope-value branch from 5a93b81 to 094c70e Compare September 10, 2023 10:10
Copy link
Member

@pokey pokey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I made some small tweaks in 094c70e. Note in particular how I added ! and !! marks to your comments and tweaked some of the example markers underneath those lines. See #1524 for more on that syntax

@pokey pokey force-pushed the migrate-python-scope-value branch from 094c70e to 22bf6ea Compare September 10, 2023 10:26
@pokey
Copy link
Member

pokey commented Sep 10, 2023

ok sorry thought you were sleeping so I force-pushed over my previous commit 😅

@pokey
Copy link
Member

pokey commented Sep 10, 2023

this PR is good to go now from my perspective; see 22bf6ea

@pokey
Copy link
Member

pokey commented Sep 10, 2023

all told, I made the following changes:

  • Added those ! and tweaked scope range markers as mentioned above
  • Removed extraneous parens from groupings where there was no predicate
  • Changed the way we do leading range to start from the end of previous named node instead of looking for =, +=, etc, as that simplified code and also fixed the failing tests that expected better whitespace cleanup
  • Added some tests to catch a few other value examples

@pokey
Copy link
Member

pokey commented Sep 10, 2023

The last issue remaining is that the new playground file has some invalid python syntax; see the complaining pre-commit step in CI

@pokey
Copy link
Member

pokey commented Sep 10, 2023

We're also not supporting iteration scope for multi-value return values, eg return a, b. That is definitely extra credit, though, so I'd be tempted to do that in follow-up PR

@pokey
Copy link
Member

pokey commented Sep 10, 2023

notice how the removal range extends all the way past the space before the = etc

image

a = 0
b = 1
c = 2
pass
Copy link
Member

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?

Copy link
Member

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?

Copy link
Collaborator Author

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

Copy link
Collaborator

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.

Copy link
Member

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

Copy link
Collaborator

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

Copy link
Collaborator

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

Copy link
Member

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

Copy link
Member

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 ?

Copy link
Member

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
Copy link
Member

@pokey pokey Sep 10, 2023

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?

Copy link
Collaborator Author

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

Copy link
Member

@pokey pokey Sep 10, 2023

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

Comment on lines +76 to +77
;; 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
Copy link
Member

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

@saidelike
Copy link
Collaborator Author

notice how the removal range extends all the way past the space before the = etc

image

Looks great. What command can you say to see the removal range?

@pokey
Copy link
Member

pokey commented Sep 10, 2023

"visualize value removal"

see docs for visualizer, although at this point I think you now know everything in that doc 😄

@pokey
Copy link
Member

pokey commented Sep 10, 2023

The last issue remaining is that the new playground file has some invalid python syntax; see the complaining pre-commit step in CI

Once this is fixed I think we're good to merge

Copy link
Member

@pokey pokey left a 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!

@pokey pokey enabled auto-merge September 10, 2023 14:48
@pokey pokey added this pull request to the merge queue Sep 10, 2023
Merged via the queue into cursorless-dev:main with commit 065f98a Sep 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lang-python Issues related to Python programming language support scope-migration Migrating scopes to next-gen scope implementation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants