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

Migrate collection item and argument scopes #2081

Merged
merged 22 commits into from
Dec 8, 2023
Merged

Migrate collection item and argument scopes #2081

merged 22 commits into from
Dec 8, 2023

Conversation

AndreasArvidsson
Copy link
Member

@AndreasArvidsson AndreasArvidsson commented Dec 2, 2023

Note that we are here just migrating markdown and yaml collection. For languages like typescript I propose that the insertion delimiter is either , for an inline collection or ,\n for an vertical collection. When the edit is constructed by our destination \n gets replaced by {indent}\n or \n{indent} depending if it's before or after. In short I don't think we actually should use leading or trailing for the insertion delimiters and the destination can take care of that on its own.

To get the correct insertion delimiter we could have a conditional insertion delimiter predicate that actually uses the collection and not the item itself to determine if it's a vertical collection/insertion delimiter.

insertionDelimiter = @list.range.isSingleLine ? ", " : ",\n"

(
  (array
    (_) @collectionItem
  ) @list
  (#conditional-insertion-delimiter! @collectionItem @list ", " ",\n")
 ) 

Edit: Just went ahead and migrated typescript argument using the above predicate. Personally I think it turned out quite nicely.

Will fix the second task
#585

Checklist

  • I have added tests
  • [-] I have updated the docs and cheatsheet
  • [-] I have not broken the cheatsheet

).flatMap((iterationRange) =>
getScopesOverlappingRange(scopeHandler, editor, iterationRange),
);
try {
Copy link
Member Author

@AndreasArvidsson AndreasArvidsson Dec 2, 2023

Choose a reason for hiding this comment

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

getDefaultIterationRange throws an error so we never got to the legacy implementation below

Copy link
Member

Choose a reason for hiding this comment

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

Is it a NoContainingScopeError? If so I'd argue we should look for that error specifically

Copy link
Member Author

Choose a reason for hiding this comment

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

True. Fixed now

Copy link
Member

Choose a reason for hiding this comment

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

Just commenting from the future to say that we removed this :D #2740

@AndreasArvidsson AndreasArvidsson added the to discuss Plan to discuss at meet-up label Dec 2, 2023
@auscompgeek auscompgeek added the scope-migration Migrating scopes to next-gen scope implementation label Dec 3, 2023
@AndreasArvidsson AndreasArvidsson changed the title Migrate markdown and yaml collection item scope Migrate collection item and argument scopes Dec 3, 2023
queries/javascript.core.scm Outdated Show resolved Hide resolved
queries/markdown.scm Outdated Show resolved Hide resolved
@pokey
Copy link
Member

pokey commented Dec 4, 2023

Pasting from slack:

  • I think insertion range is the wrong name tho because that’s too easily confused with “to” destination, ie that’s what I would assume “insertion range” means. It’s unfortunate they’re not equal
  • Maybe insertionBoundary? adjacentDestinations? beforeAfterDestination?
  • I mean tbh the clearest would be separate positions for each. Using a range is kind of a shortcut. And in this case we only need one side I believe, in which case just beforeDestionation or destinationBefore. I think that’s super clear
  • Then we could have destinationTo for the “to” destination, eg for Support destination pseudo-scopes #1631
  • for destinationBefore / destinationAfter, they’d be zero-width
  • I think that’s nice and consistent - Or we could have it be an arg, eg (#destination! "before" @foo)
  • all that being said, I do wonder if what we really want is something semantically richer, along the lines of:
    • eg markdown / yaml lists are newline-delimited, indentation-nested, with given start of line marker
  • I feel like anything less is kind of a stopgap that we’re going to end up having to work around

to discuss Plan to discuss at meet-up

@AndreasArvidsson
Copy link
Member Author

AndreasArvidsson commented Dec 4, 2023

Another thing I just noticed when it comes to the removal range of markdown and yaml items is that the "insertion range" should be used for removal instead of the content range. You of course want to remove the leading dash.

I would argue that we here have two different content ranges actually. We have the outer range containing things like the dash or asterisks. This range is what we use when we remove or when we create insertions before or after. We then have the inner content range which actually has the text content. This is what we use for things like copy, change and so on.

We definitely need to discuss this tomorrow

Edit: We could use this "extended content range" in different actions. For example copy and bring might actually include the prefix while change and take doesn't. That kind of thing.

Edit2: This issue could benefit from two different content ranges: #2014

@AndreasArvidsson
Copy link
Member Author

Another thing that just struck me(the item patterns are getting quite crowded) is why do we need to give a start and an end to the leading and trailing ranges? shouldn't they always terminate at the content range(or extended content range)? I think we can just use @_.leading and @_.trailing with optional .startOf/.endOf. We already know that the leading terminates at the start of the content range and the trailing starts at the end of the content range.

@pokey
Copy link
Member

pokey commented Dec 7, 2023

Filed #2106 to capture our discussion

@AndreasArvidsson
Copy link
Member Author

@pokey Updated according to today's meet up

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.

Looking good! I almost see a way to keep the prefix field out of the Target interface, but prob better to let it leak out for now just to get this thing out

I left one comment; if we don't get an answer from @josharian on #2108 in the next 24hrs let's push forward anyway; I agree it's a nice slick syntax

);
const prefixRange =
rawPrefixRange != null
? new Range(rawPrefixRange.start, contentRange.start)
Copy link
Member

Choose a reason for hiding this comment

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

We should prob only do this if we decide to go ahead with #2108

Copy link
Member Author

Choose a reason for hiding this comment

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

I really don't like having to do unnecessary syntax, but sure we can await that discussion.

).flatMap((iterationRange) =>
getScopesOverlappingRange(scopeHandler, editor, iterationRange),
);
try {
Copy link
Member

Choose a reason for hiding this comment

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

Is it a NoContainingScopeError? If so I'd argue we should look for that error specifically

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.

🎉

@pokey pokey added this pull request to the merge queue Dec 8, 2023
Merged via the queue into main with commit 40a6fee Dec 8, 2023
13 checks passed
@pokey pokey deleted the collectionItem branch December 8, 2023 21:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope-migration Migrating scopes to next-gen scope implementation to discuss Plan to discuss at meet-up
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants