Feature request: custom text objects/motions

[timkendrick]

I'm an Atom vim-mode-plus user who's been keeping an eye on VSCode for a while: one of the main things that's holding me back from switching is the inability to define various text objects and motions that I've grown accustomed to.

Some examples of custom text objects in other 'vimplementations':

• vim-mode-plus-subword-movement (Atom vim-mode-plus)
• vim-textobj-function (Vim)
• vim-textobj-indent (Vim)
• vim-textobj-user (Vim) ...etc

Is there any chance that this kind of extensibility will be available for text objects and motions within VSCode Vim some day?

[johnfn]

Our current policy on extensions is that while we probably won't implement them ourselves, we're completely open to other users implementing them. We're also completely fine with merging them into VSCodeVim core (generally speaking under a flag).

[timkendrick]

Sounds great, thanks for the fast response!

[johnfn]

Gonna keep this open as it's a valid feature request.

[tylerthehaas]

I also would very much like to see this. Any work going on with this?

[sunnyrjuneja]

Hey everyone,

Subword support has been added to VS Code in 1.25 (https://github.com/Microsoft/vscode/pull/48023). Is it possible to enable subword for motion hot keys?

[muhajirdev]

Any progress on this?

[skywind3000]

Still no progress ??

[sql-koala]

subword movement is supported: https://github.com/VSCodeVim/Vim/blob/master/README.md#camelcasemotion indent is also supported, keys: ii, ai

[danielo515]

I'm particularly interested on the function text object. Is it possible to take advantage of any LSP to not have to parse it? I mean, can this extension communicate with LSP?

[nwaywood]

A text object not mentioned here yet that I use a lot is https://github.com/kana/vim-textobj-line

[nudopnu]

I would also love to see xmlattr https://github.com/whatyouhide/vim-textobj-xmlattr

[haukurb]

A text object not mentioned here yet that I use a lot is https://github.com/kana/vim-textobj-line

For any who also ended up here when looking for line text objects, most of it can be emulated with the "before-after" functionality:

{
    //   ...
    "vim.normalModeKeyBindingsNonRecursive": [
        // hacks for line text object
        {
            // delete inner line
            "before": ["d", "i", "l"],
            "after": ["^", "d", "g", "_"],
        },
        {
            // change inner line
            "before": ["c", "i", "l"],
            "after": ["^", "c", "g", "_"],
        },
        {
            // go replace inner line
            "before": ["g", "r", "i", "l"],
            "after": ["^", "g", "r", "g", "_"],
        },
        {
            // go UPPER inner line
            "before": ["g", "U", "i", "l"],
            "after": ["^", "g", "U", "g", "_"],
        },
        {
            // go upper inner line
            "before": ["g", "u", "i", "l"],
            "after": ["^", "g", "u", "g", "_"],
        },
    ],
    // ...
    "vim.visualModeKeyBindingsNonRecursive": [
        // hacks for line text object,
        {
            // select inner line
            "before": ["i", "l"],
            "after": ["^", "v", "v", "$", "o"],
        },
        {
            // select around line
            "before": ["a", "l"],
            "after": ["0", "v", "v", "$"],
        }
    ],
    // ...
}

This catches the most frequent usages and is easily extended to "around-line" objects (for preceding space + trailing space).

The surround command ys uses (I think) operatorPendingMode so it needs a different approach.

[max-sixty]

In the spirit of sharing hacky regexes, here's an attempt at a selecting comment block. g; selects a contiguous comment block while g: selects comment blocks separated by newlines.

g; currently has an issue in that the selection moves to the bottom of the buffer; thoughts on fixing it are very welcome!

```json // Selects single-line comments blocks, starting with `#` or `/` // doesn't expand over blank lines, does // We have to write out the whole regex in single characters, which makes it // illegible, unfortunately. But the regex is: // - `^(\s*[^\s#/])` for `` // - `^(\s*[^\s#/]|$)` for `` { "after": [ "?", "^", "(", "\\", "s", "*", "[", "^", "\\", "s", "#", "/", "]", ")", "", "j", "V", "/", "^", "(", "\\", "s", "*", "[", "^", "\\", "s", "#", "/", "]", ")", "", "k" ], "before": ["g", ":"] }, { "after": [ "?", "^", "(", "\\", "s", "*", "[", "^", "\\", "s", "#", "/", "]", // By hitting this key without hitting the next one yet, the top of the // file is highlighted, which makes moves the selection to the bottom of // the screen. TODO: find a way of entering the whole regex without a // redraw. If we paste it, then it works, so some way is possible. "|", "$", ")", "", "j", "V", "/", "^", "(", "\\", "s", "*", "[", "^", "\\", "s", "#", "/", "]", "|", "$", ")", "", "k" ], "before": ["g", ";"] }, ```

---

I'd very much like a a feature to define a mapping between a chord and a text selection — so rather than having to define dil, dal, cil, cal, vil, val etc — we could just define il & al mean, and for the extension to handle it in each action.