Vim: Add support for text-object like motion for arguments

[fabrik42]

This is a feature request. 🙏

First of all, thank you for this great extension! I am currently considering switching vom Spacemacs (evil) to VS Code and the Vim extension is crucial for me.

The main thing that is missing for me is the following motion:
argtextobj.vim or evil-args.

This is extremely handy during development, especially refactoring. Is there any chance this will get implemented in the Vim extension?

An example from the evil-args README

evil-inner-arg/evil-outer-arg

Select an inner/outer argument text object.

For example, cia transforms:

function(ar|g1, arg2, arg3)
function(|, arg2, arg3)

or

function(arg1, ar|g2, arg3)
function(arg1, |, arg3)

daa transforms:

function(ar|g1, arg2, arg3)
function(|arg2, arg3)

or

function(arg1, ar|g2, arg3)
function(arg1, |arg3)

---

Let me know what you think!
Best, Christian

[johnfn]

I'm a bit confused how cia is different than caw and how daa is different than df (delete find space). They seem the same to me. :) If it's just the keymappings you miss, you can use our remapping feature to map cia to caw and daa to df.

[fabrik42]

These are just the most simple examples, the movement can to much more, like handling types and more complex expressions in an argument.

For example deleting an argument like myfunc(int counter<|>+1) with daa is supported (<|> is the cursor).

[calebeby]

I really think this would be an awesome feature to have, it was probably my most used text object in Vim. Is there any chance this could be implemented?

Thanks!

[delaaxe]

I find the arguments plugin to be just as useful as surround!

[fabrik42]

@joonro Hi! Is there any chance this will make it into VSCodeVim? If there is general interest, I could also try to contribute and help!

Cheers, Christian

[J-Fields]

@fabrik42 None of the maintainers plan on doing this any time soon, I think. Feel free to submit a PR!

[skywind3000]

I wish to create a PR, but I haven't written any typescript before.

[lmNt]

I have started working on this feature, because it bothers me to not have this movement available.
I'm also not a typescript programmer, so my pace and code-quality may still be a bit sub-par.

However, inner-arg already works kind of alright - some edge-cases like multi-line need some more work. Also it's still not clear to me what the expected behavior should be when the cursor is on a delimiter.

outer-arg should be easy, once inner-arg is behaving in a nice manner.

Check the progress in my fork. I think I can get it done in the next couple of days.
Also feel free to contribute in any way :)

[lmNt]

Good news, I'm almost done and am quite satisfied with the results as of now. Almost all test-cases I wanted to cover are implemented and pass (except 3 minor cases, where I need to understand some vscode-vim behavior).
While building this movement, I mostly mimicked the targets.vim's behavior (since that is what I am used to in vim).

There is one edge-case I am currently not covering and am not sure, if the effort really would be worth it (actually targets.vim has the same _flaw_). In case of a parentheses mismatch, comma-separated arguments still will be treated as arguments, so cia in:

[b|ar)

would still result in

[)

even though [ does not match ). I currently can't think of cases where this would cause any issues, but I am open for enlightenment.

Before making the PR, I still want to implement settings, so that the delimiters can be specified by the user. Currently only ,, [] and () are used as delimiters by default, but depending on the language it may be interesting to support {}, <> and ;, etc.

[J-Fields]

@lmNt Exciting to hear! Feel free to submit a WIP PR for feedback before you're 100% complete

(also feel free to bug me if you have any questions about the codebase)

[delaaxe]

JetBrains implemented this in their IdeaVim plugin: https://github.com/JetBrains/ideavim/blob/master/CHANGES.md (version 0.56)

[garrettm]

I'm interested in this as well, what's the state of things @lmNt ?

[lmNt]

Really sorry for the delay. I had a lot of stuff piled up that had priority.

I still have some untested Code laying around for handling delimiters in strings, which is kind of fiddly to do, to be honest.
Apart from that it‘s more or less finished and useable in its current state.

I’ll try to get to it ASAP.

[garrettm]

@lmNt no need to apologize! I might be able to take a look as well if you have a list of stuff that’s left to do?

[lmNt]

What do you guys think of string handling, e.g. how argtextobj.vim does it?
I'm really hesitant implementing that feature, because it hugely complicates the logic, has many edge cases (e.g. triple-quoted strings, multiline strings, string-interpolation, escaped strings) and does not really give a that big of a benefit.

The following examples are taken from the argtextobj.vim behavior:

Example where I like how it behaves:

(this, is, "te|xt,")
cia
(this, is, |)

there it ignores the delimiter inside the string, which you would expect.

However, I really don't like this behavior (also taken from argtextobj)

(this, is, "(quoted text, |with, nested delimiters)")
cia
(this, is, |)

Are there any opinions/preferences on this?
If this turns out to be a must-have for a lot of people, I would like to compile a suite of tests to define the behavior. So feel free to contribute some test-cases.
Otherwise we could just merge this PR in its current feature-set (IMHO it covers 99.9% of my use-cases) and add string handling later on. I'd like to hear what others have to say.

[delaaxe]

I'm really hesitant implementing that feature, because it hugely complicates the logic,

Best to keep it simple in my opinion

[skywind3000]

textobj-parameter is similar to argtextobj.vim, and it is more simple (just 400 lines).

[J-Fields]

Otherwise we could just merge this PR in its current feature-set (IMHO it covers 99.9% of my use-cases) and add string handling later on.

This is my instinct. I'd like to get this in the code base with some edge cases like this which we can improve on later, instead of letting it become monstrously complicated and languish as a PR while I try to find time to review it all.

[garrettm]

I’d vote for merging as well

[garrettm]

@J-Fields will this be on by default in an upcoming release of the addon? Is there an ETA for that? This is one of the biggest things holding me back from using VSCode full time :)

[J-Fields]

will this be on by default in an upcoming release of the addon?

Yup

Is there an ETA for that?

Most likely this weekend, but I make no guarantees