Implement next/last argument text-objects from targets.vim

[AsterisMono]

What this PR does / why we need it:
Implements next/last argument text-objects from targets.vim.
Use <operator><i/a>na/la anywhere to access the next/last argument. It will look for the next/last one in the buffer if there are no arguments under the cursor.

Which issue(s) this PR fixes
Contributes to #601

Special notes for your reviewer:

• Please be noted this is a beta thing for now! Most of the time it will work as expected, but there can be bugs in rare cases.
• Please let me know if there's any case that I failed to cover in the unit tests :D

[AsterisMono]

I think it's ready for review and trying out. However, some tests unrelated to this implementation seem to fail.

22 tests will fail (on master it's 16), I tested some of them by hand and they seemed to be okay 🤨

Test log here

[elazarcoh]

Thanks for the PR! I'm already waiting for it to get merged!
I didn't try it yet, I only read the code. One thing I'm concerned about is how f(a[1, 2], b[1, 2]) would behave in different scenarios. My instinct tells me that, it should jump between a and b, and not from a to 1 for example. Does that make sense? What the current implementation does?

[AsterisMono]

@elazarcoh

Just made a quick test and it will indeed jump to 1 instead of b.
However, this is the default behavior in the original targets.vim plugin (and also for <operator>ia actions) that's only if the cursor is positioned inside [], so I think I'm not gonna make a change here.

If you need the argument text object to work with brackets only, you can try modifying vim.argumentObjectOpeningDelimiters & vim.argumentObjectClosingDelimiters and remove the square brackets 😊

[elazarcoh]

Okay.
just want to add that it isn't consistent with the ia behavior, as cia for example would select a[1,2].
@J-Fields should make the last call on it, I guess.
also, we can merge it and later modify the behavior if we want.

[AsterisMono]

Maybe we can get a toggle switch on this.

If checked then make it work with brackets only 🤔

[J-Fields]

Logger API changed; should just be Logger.debug('whatever')

[AsterisMono]

Got it —— I'm currently busy with academic stuff, would come back later to address the issue and maybe revamp the ineffective algorithm.

By the way, I wonder what's your opinion towards this? Should we implement the exact behavior of the original plugin, or upgrade it to recognize the brackets it's currently in?

Thanks for the PR! I'm already waiting for it to get merged! I didn't try it yet, I only read the code. One thing I'm concerned about is how f(a[1, 2], b[1, 2]) would behave in different scenarios. My instinct tells me that, it should jump between a and b, and not from a to 1 for example. Does that make sense? What the current implementation does?

Okay. just want to add that it isn't consistent with the ia behavior, as cia for example would select a[1,2]. @J-Fields should make the last call on it, I guess. also, we can merge it and later modify the behavior if we want.

[J-Fields]

By the way, I wonder what's your opinion towards this? Should we implement the exact behavior of the original plugin, or upgrade it to recognize the brackets it's currently in?

Don't have a strong opinion. Being consistent with original plugin is generally better, but I'll leave it up to you