Add text-based surrounding pair implementation

[pokey]

• If we are in a lang without syntax tree, use text-based
• If we are in a string or comment within a language with a syntax tree, start with text-based, but switch to parse tree if no delimiters found within current string / comment
  • Bonus: Treat a sequence of comments or strings as a single comment / string from this perspective
• Impl for text-based is to just walk left from char, keeping track of what you see and walking over pairs

[maciejklimek]

Why do we want to switch to this method for languages with syntax tree?

[pokey]

The main driver for me was being able to select inside brackets within a string, esp eg in talon capture definitions. I could see an alternative where we first run the text-based version if we're within a string or comment, then switch to syntax tree version if we don't find delimiters within the given string / comment. But @AndreasArvidsson may have other thoughts

[pokey]

Fwiw one disadvantage of text-based approach in languages with syntax tree is that it might be tougher to support those pair types where we know it's a pair because of its node type, eg for html tags

[AndreasArvidsson]

Combining text with parse tree sounds good

[pokey]

ok @maciejklimek your code lives to see another day 😊. I updated issue title / description. Lmk if makes sense to you

[maciejklimek]

I think a good general rule is to have a wide choice of different modifiers available at the backend(vscode side),
provide sensible default at the talon side, but also make it configurable if the user wishes to do a slightly different thing.
In this case, this would mean having a different modifier or and argument to an existing modifier that would implement the new behaviour.
Currently though, I think configuring cursorless on the talon side is not that easy because it requires one to fork the code, or do some weird stuff like sed and the code is changing so fast that forking is not good.

what do you think?

[pokey]

Not sure I totally follow, but would a VSCode extension setting not make sense here? Can you give an example of the type of configuration you're after?

[maciejklimek]

I wasn't sure if the behavior in the second case(the one with the string), would be always preferred.
I imagine that one could prefer to take the syntax tree based matching, instead of the text one in the case with the string.
This is probably a very infrequent case, but it seems to me we could support even this case,
with very low cost.
I think that having this as parameter of the request, is better than having it as the extension setting in vscode,
cause it is more flexible.

But this case is infrequent enough, that i am also fine with the version you proposed :)
I really need this text version in these talon files, I often want to clear the strings with clear maching

[AndreasArvidsson]

I think we can start with one behavior and if people find that they have problem with it we can always add a setting or an additional word/modifier later. Does that work for every one?

[maciejklimek]

👍

[pokey]

works for me. fwiw we could potentially get around needing the override behaviour using #124, or by making it so that the scope finder code will expand again if you currently have something of that scope type selected. With the latter you'd just repeat the command to get the bigger scope