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

Implement generic "every" logic #797

Closed
2 tasks
pokey opened this issue Jun 28, 2022 · 0 comments · Fixed by #1031
Closed
2 tasks

Implement generic "every" logic #797

pokey opened this issue Jun 28, 2022 · 0 comments · Fixed by #1031

Comments

@pokey
Copy link
Member

pokey commented Jun 28, 2022

  • For "every <scope> this" with empty selection, expand to iteration scope and yield every scope in that range
  • For "every <scope> this" with non-empty selection, yield every scope that has non-empty overlap with selection
  • For "every <scope> air", expand to iteration scope and yield every scope in that range
  • For "every <scope> block", yield every scope that has non-empty overlap with selection

For reference, this is what weakness looks like:

  • For "if wrap this" with empty selection, wrap containing statement
  • For "if wrap this" with non-empty selection, wrap containing statement
  • For "if wrap air", wrap containing statement
  • For "if wrap block", just wrap exact block

Possible solution is to change CursorMarkStage to only return weak target if selection is empty. In that case, weakness for wrap now looks like:

  • For "if wrap this" with empty selection, wrap containing statement
  • For "if wrap this" with non-empty selection, just wrap exact selection
  • For "if wrap air", wrap containing statement
  • For "if wrap block", just wrap exact block

Then we would make it so that for "every", we expand to iteration scope for weak targets and for non weak targets we yield every scope that overlaps. Then our proposal at the top works because the first in the third are week so they expand to iteration scope but the second in the fourth do not the because they are not weak

Ideally as much as possible is implemented in new EveryScopeStage, but will need to think a bit about how much autonomy scope handlers need

We should probably let EveryScopeStage decide whether to expand to iteration scope, and then just pass input target content range and Boolean indicating whether to expand

pokey added a commit that referenced this issue Apr 19, 2023
- Partially addresses #616
- Partially addresses
#436
- Depends on #1396

## Todo
- [x] **[DISCUSS]** What to do about fallback `iterationScope`? That's
the only thing that is a regression here.
- [x] File issues for FIXMEs
- [x] File issue for defining iteration scopes. Can probably reuse most
of the code from the regular scope handler other than creating the
target
- [x] File issue to add unit tests for scope handlers
- [x] File issue to add some Python scope types where multiple can end
at the same point (due to lack of closing brackets)
- [x] Add test that checks no scope types are duplicated between legacy
and new definition, or file issue to add test
- [x] File PR for my 7783da6 (Add support for domain, leading, trailing,
interior) #1427
- [x] Look through comments on this thread for anything worth filing /
doing
- [x] Open as new PR?
- [x] Remove extraneous test cases
- [x] Double check
#629 (comment);
a lot of those tests we already have for the generic modifier code
- [x] Make sure changes to parse-tree-extension are shipped
- [x] Close #785 if
we fix that
- [x] Comment on #484 saying the process has started and providing link
to example
- [x] Close #797 if
we fix that

---------

Co-authored-by: Pokey Rule <755842+pokey@users.noreply.github.com>
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 a pull request may close this issue.

1 participant