Argument Text Object Count Unappreciated

[orbisvicis]

Given call foo("bar", "baz", "bla", "robot") and any argument text input with counts such as v2aa, c3ia, the cursor is repositioned to the start-of-line and no object is modified by the operator.

[orbisvicis]

I see, it works nested as with pairs. I guess the behaviour I'm looking for is more in line with vim's iw [count] argument. Can anything be done? I was hoping for something like vim-angry (see example).

[orbisvicis]

I see, this would break nested arguments such as

function(a, 33, [1, 2, 3, 4, 5, ], 61234, V="one, two", )
function(a, f2(1, 2, 3), b)

There should be a method for specifying both depth and breadth.

[orbisvicis]

There are two approaches, both involve adding the [fb] actions to complement [nl].

First

The problem with target's [count] is it encodes both depth and breadth. So when specifying a non-adjacent offset (such as: [this] [] [from this]), all the intermediate depths have to be counted, which is quite tedious. So I propose a 2-[count] strategy:

[operator][depth-count][modifier][breadth-count][action][object]

The default [depth] for shifted objects ([breadth != 1) is the innermost level, for the current object it is the current level. [breadth] starts at 1 and increments outwards.

Examples:

v2ilb       (modifiers default to 1)
                                                       +
    a ( b ( cccccccc ) d ) ( e ( ffffff ) g ) ( h ( iiiiiiii ) j ) k
                            ++++++++++++++++

vi2lb       (modifiers default to 1)
                                                       +
    a ( b ( cccccccc ) d ) ( e ( ffffff ) g ) ( h ( iiiiiiii ) j ) k
           ++++++++++                        

v2i2nb
            +
    a ( b ( c ( d ( eeeeeee ) d ) c ) b ) a
               +++++++++++++++++

v2ibb
                                                +
    a ( b ( cccccccc ) d ) ( e ( ffffff ) g ) ( h ( iiiiiiii ) j ) k
                            +++++++++++++++++++++++++++++++++++++

vibb
                                                       +
    a ( b ( cccccccc ) d ) ( e ( ffffff ) g ) ( h ( iiiiiiii ) j ) k
                                +++++++++++++++++++++++++++++

v2ib2ibb    (more complicated, requires chaining multiple text-object operations)
                                                       +
    a ( b ( cccccccc ) d ) ( e ( ffffff ) g ) ( h ( iiiiiiii ) j ) k
                            +++++++++++++++++++++++++++++++++++++

This illustrates a problem with [bf] and matched pairs: inwards->outwards depth specification complicates "natural" specification of adjacent objects. Perhaps it would make more sense for [fb] to invert [depth] to work outwards->inwards.

Perhaps most sensible (and simplest) is to ignore [depth] for [bf]: vim-targets simply selects all unmatched in-between paired objects:

vibb
                                                       +
    a ( b ( cccccccc ) d ) ( e ( ffffff ) g ) ( h ( iiiiiiii ) j ) k
                            +++++++++++++++++++++++++++++++++++++

However I find this approach limiting. The most strightfoward approach to solving this selection problem is to add a second (optional) depth specification:

[operator][source-depth-count][modifier][breadth-count][bf][target-depth-count][object]

v2ib2b
                                                       +
    a ( b ( cccccccc ) d ) ( e ( ffffff ) g ) ( h ( iiiiiiii ) j ) k
                            +++++++++++++++++++++++++++++++++++++

Second

Tack on [fb] without any additional modifications (ie, use the default counting scheme):

Examples:

vibb
                                                +
    a ( b ( cccccccc ) d ) ( e ( ffffff ) g ) ( h ( iiiiiiii ) j ) k
                            +++++++++++++++++++++++++++++++++++++

v2ibb
                                                       +
    a ( b ( cccccccc ) d ) ( e ( ffffff ) g ) ( h ( iiiiiiii ) j ) k
                                +++++++++++++++++++++++++++++

Once again, this particular selection isn't possible additional changes:

1. Use vim-target's current counting scheme, but have [bf] accept a second target, forming a range:

[operator][target-count][modifier][source-count][bf][object]

v1i2bb      (extraneous '1' added for clarity)

                                                       +
    a ( b ( cccccccc ) d ) ( e ( ffffff ) g ) ( h ( iiiiiiii ) j ) k
                            +++++++++++++++++++++++++++++++++++++

1. Add [BF] that automatically connects in-between paired objects. Though it is possible to make this the default behviour of [bf], that would more functionality than acceptable.

v1Bb
                                                       +
    a ( b ( cccccccc ) d ) ( e ( ffffff ) g ) ( h ( iiiiiiii ) j ) k
                            +++++++++++++++++++++++++++++++++++++

[orbisvicis]

(This is just a reordering of the first proposal: same concept, different text-object.)

Perhaps an even better alternative:

[operator][-][source-depth-count][not-a-number][.][-][breadth-count][not-a-number][-][target-depth-count][modifier][object]

Easier to type, remember, and reason with. It just looks more complicated, but most components are optional, or discarded spacers/delimiters. Also more flexible: negative depths can have arbitrary alternative meanings, such as relative-to-current-depth, or outwards->inwards (preferred, I think).

number priorities:

1: source-depth-count
2: breadth-count, target-depth-count
3: source-depth-count, breadth-count, target-depth-count

[orbisvicis]

OK, this could be awesome.

[wellle]

Unfortunately plugins can't handle counts themselves, so there's no real way to expand it in the way you proposed. Vim is taking care of counts and plugins can access those.

Personally I would like to have 3d4ana to go to the forth next argument and delete three arguments. Then 3daa could delete three arguments, while d3aa would delete the argument three levels above. But there is no such distinction between those counts. If you give both counts they are actually just multiplied.

So I'm afraid what you suggest is impossible to build. We could however consider a different text object like A that uses counts differently. But I'm not sure if that's actually helpful or just confusing.

As for your initial request, to delete all arguments I just do di). To delete three arguments I usually do daa...

repositioned to the start-of-line

That should not be the case, please try again with the latest version of targets.vim

[orbisvicis]

If you give both counts they are actually just multiplied.

Hmm, didn't know that. And there are subtitle differences between operators, ie d->v.

We could however consider a different text object like A that uses counts differently.

What exactly do you mean? Having vim take care of counts just implies custom [count]s can't be used around the operator itself. They can still be used anywhere within the text object specification - just use getchar() to read them:

[can't-have-number-here][operator][can't-have-number-here][count][text-object-can't-start-or-end-with-number]

Personally I would like to have 3d4ana ...

I agree, having [count] surround the operator is very intuitive. That said, if you're willing to shift the [count]s into the text-object itself, you can still get this behaviour - though I think first you should consider my alternative counting schemes. They can still be accomplished.

To delete three arguments I usually do daa..

Hmm, that is very handy, though I wish it would work for other operators like c or v.

That should not be the case, please try again with the latest version of targets.vim

Yes, that was fixed in #106 (567a293)

[wellle]

just use getchar() to read them:

The problem with getchar is that it breaks repeatability. It could be fixed by adding vim-repeat as a hard dependency, but that's quite a bit of work and I'm not sure it's worth the effort.

though I think first you should consider my alternative counting schemes

I'm not sure I fully understand. Could you give me a couple of examples to illustrate how they would be used?

[orbisvicis]

It could be fixed by adding vim-repeat as a hard dependency, but that's quite a bit of work and I'm not sure it's worth the effort.

You're right, yield on return isn't high enough.