"take round" also takes leading $

[jmegner]

"take round air" on $($a) selects $($a), but it should select ($a).

[pokey]

That is intentional. We consider the $ to be part of the pair

[AndreasArvidsson]

Defined here https://github.com/cursorless-dev/cursorless/blob/3242176925e483e54a6e41c91ac651999fb924a2/packages/cursorless-engine/src/processTargets/modifiers/surroundingPair/delimiterMaps.ts#L23

To be honest I've never been one hundred percent sure about that decision.

[pokey]

The idea is to include the full delimiter token, similar to the way we handle f-strings and triple quotes in Python. But if @AndreasArvidsson @josharian and @jmegner all want to push for this one I'll cave

[jmegner]

....I now better appreciate the benefits of including the dollar sign, but I fear it's just going to cause more surprise and mistakes than benefit. Let me play with it more now that I know it is deliberate.

[AndreasArvidsson]

After discussion with @pokey we came to the following conclusion

• Matching pairs should be dumb and don't try to expand to anything else than the given pair
• the string scope type should be implemented per language(eg f"foo" would be implemented by python) with a fall back to matching pairs. This is similar to what we do for item
• The argument scope type could be used for interpolated variables like ${foo}

[pokey]

the string scope type should be implemented per language(eg f"foo" would be implemented by python) with a fall back to matching pairs. This is similar to what we do for item

Note that one drawback of this approach is that if you have something like

aaa = "bbb 'ccc' ddd"

Saying "string cap" will give you the whole string "bbb 'ccc' ddd" rather than 'ccc'.

However, we have the same problem with "item", where we'll leap to the syntactic item even if you're inside a smaller textual item. We should be able to fix both of these issues more easily once item and pair are migrated to next-gen scopes, so I don't think this problem should keep us from implementing the proposal in @AndreasArvidsson's comment in the meantime

[AndreasArvidsson]

Yes if you just want to match on the ' delimiters you should use a matching pair and not the string scope type. Now we have just overloaded the same word to mean both of them, but in the future we would have this distinction.

[pokey]

Yes if you just want to match on the ' delimiters you should use a matching pair and not the string scope type. Now we have just overloaded the same word to mean both of them, but in the future we would have this distinction.

I don't think that lines up with what you propose in your bullet points above. See where it says "the string scope type should be implemented per language ... with a fall back to matching pairs"

[AndreasArvidsson]

I see no contradicition in that? The string scope is defined per language and a string in a programming language is (mostly) well defined. Matching quotes inside a string you would have to use matching pairs for.

[pokey]

I think the problem I propose in https://github.com/cursorless-dev/cursorless/issues/1812#issuecomment-1712427246 can be solved by a oneOf matcher combining matching pairs and syntactic string. Then it would just be nested as we'd like. We can do this once matching pairs are migrated to next-gen