-
-
Notifications
You must be signed in to change notification settings - Fork 85
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
Conversation
packages/cursorless-engine/src/languages/TreeSitterQuery/QueryCapture.ts
Outdated
Show resolved
Hide resolved
packages/cursorless-engine/src/languages/TreeSitterQuery/queryPredicateOperators.ts
Outdated
Show resolved
Hide resolved
).flatMap((iterationRange) => | ||
getScopesOverlappingRange(scopeHandler, editor, iterationRange), | ||
); | ||
try { |
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.
getDefaultIterationRange
throws an error so we never got to the legacy implementation below
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.
Is it a NoContainingScopeError
? If so I'd argue we should look for that error specifically
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.
True. Fixed now
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.
Just commenting from the future to say that we removed this :D #2740
packages/cursorless-vscode-e2e/src/suite/fixtures/recorded/languages/markdown/chuckItem2.yml
Show resolved
Hide resolved
packages/cursorless-vscode-e2e/src/suite/fixtures/recorded/languages/yaml/changeEveryItem3.yml
Show resolved
Hide resolved
Pasting from slack:
to discuss
|
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 |
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 |
Filed #2106 to capture our discussion |
@pokey Updated according to today's meet up |
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.
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) |
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 should prob only do this if we decide to go ahead with #2108
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 really don't like having to do unnecessary syntax, but sure we can await that discussion.
).flatMap((iterationRange) => | ||
getScopesOverlappingRange(scopeHandler, editor, iterationRange), | ||
); | ||
try { |
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.
Is it a NoContainingScopeError
? If so I'd argue we should look for that error specifically
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.
🎉
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"
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