Add vim-like jump to textobject

[Adir-Shemesh]

Support matching the nearest textobject even in cases where the cursor is outside it, like in vim. Examples:

1. this is (some text), assume the cursor is in the start of the line - mi( will select some text.

2. dict(
       key1="val1",
       key2="val2",
   )

   when the cursor is somewhere on key2 and mi" is pressed, val2 will be selected (unlike the current behavior which selects ,\nkey2=)

see more examples in the test cases.

In order to avoid the ambiguity in example 2, surrounding pairs of the same character (like quotes) are only supported in the current line. This also matches the behavior of vim and vim-surround.

[the-mikedavis]

I'm strongly opposed to this behavior: it makes it difficult to predict what will happen when you have multiple cursors across a document either inside of or nearby textobjects, a problem that vim doesn't have because it isn't multicursor-centric. See #4123 where we removed similar functionality in the past for increment/decrement (<C-a>/<C-x>).

[Adir-Shemesh]

I'm strongly opposed to this behavior: it makes it difficult to predict what will happen when you have multiple cursors across a document either inside of or nearby textobjects, a problem that vim doesn't have because it isn't multicursor-centric. See #4123 where we removed similar functionality in the past for increment/decrement (<C-a>/<C-x>).

I see, this makes sense. I do think that such functionality is useful in structured documents with multiple cursors (if you expect it). how would you feel about either:

1. adding a config to toggle this behavior?
2. making it an M command? (i.e. m keeps the current behavior, M jumps to text objects)

[doy]

this also just entirely breaks selecting multiline strings, which feels like a pretty significant regression here - i don't think only supporting surrounding pairs of the same character on a single line is very reasonable

[Adir-Shemesh]

@the-mikedavis @doy I moved the new behavior to a new M command, what do you think?

[pascalkuthe]

I don't see us moving forawrds with this, the current behaviour is very intentional. Altenratiev editing paradimes can be implemented in plugins. Thank you for contributing!