Questions on a couple of edge cases

[nkgm]

It is my ambition to help cover a few of the edge cases this plugin's problem domain presents. To that end, I'd be interested to get your take on the following:

1

                     ......
                \ [ '[', ']' ],
                     └─ va[ ─┘

normal! va[ behaves identically so this is most likely a vim bug.

2

                          .....
                \ [ '<', ',>' ],
                           └─┘
                           via

A subsequent ia here throws error.

3

                          .....
                \ [ '<', ',>' ],
                          └─┘
                           vaa

These cases can be pretty hard to solve, but using synIDattr could make this task more manageable. I can see why you might choose to avoid something like that, but I've used this technique to create a more reliable JS function object (including arrow functions), and it works pretty well. Thoughts?

[wellle]

It is my ambition to help cover a few of the edge cases this plugin's problem domain presents.

@nkgm: Thank you for this 👍

I believe the main issue you're raising here is basically handling quotes in argument text objects, right? This already came up in #107 and #111. I still think this might be a useful addition, but it seems quite complex to implement and I didn't get into actually looking into this yet. But once I do I will see if synIDattr might be helpful. But generally, as you mentioned, I'd like to keep the plugin as language/syntax agnostic as possible.

A subsequent ia here throws error.

This seems to be the same issue as reported in https://github.com/wellle/targets.vim/issues/189, right?

[nkgm]

Would you say (1) is a vim bug, considering the mixed handling of quoted brackets (it skips the ']' but not the '[')?

This seems to be the same issue as reported in #189, right?

Yes it's identical in that it happens for the last arg.

I believe the main issue you're raising here is basically handling quotes in argument text objects, right?

Not just argument text objects. String literals and comments appear to be the source of a lot of headaches when constructing any type of (syntax) aware text object. Add multiline strings to the mix and the problem at hand becomes that much harder. I dont have as much experience building custom text objects so I could be wrong, but I believe proper quote accounting to be impractical and/or unattainable (quote and multiline escaping considered, you can't really know you're not in a string literal (or comment) unless you backtrack all the way to file start, no?). If anything, programming languages have their own ways of doing (multiline) strings/comments. To do this properly (besides the ridiculous amount of work to get right for every language), you'd end up duplicating a lot of what's already there.

It doesn't need to be one or the other: you may choose to use synIDattr to get you out of the woods when available, and keep classic behavior when it's not. A good syntax plugin is not an unreasonable prerequisite for good quality text objects. On the other hand, if my text looks black and white, I wouldn't be surprised if some of the more advanced text objects aren't spot on.