remappings: implement ttimeoutlen

[kswope]

• Click thumbs-up 👍 on this issue if you want it!
• Click confused 😕 on this issue if not having it makes VSCodeVim unusable.

The VSCodeVim team prioritizes issues based on reaction count.

---

Not sure if this is a bug report or a feature request

This example works

    "vim.otherModesKeyBindingsNonRecursive": [
        {
            "before": ["Z", "Z"],
            "after": [],
            "commands": [
                {
                    "command": "workbench.action.files.save",
                    "args": []
                },
                {
                    "command": "workbench.action.closeActiveEditor",
                    "args": []
                }
            ]
        }
    ]

This modification of example doesn't

    "vim.otherModesKeyBindingsNonRecursive": [
        {
            "before": ["s", "s"],
            "after": [],
            "commands": [
                {
                    "command": "workbench.action.files.save",
                    "args": []
                },
                {
                    "command": "workbench.action.closeActiveEditor",
                    "args": []
                }
            ]
        }
    ]

"s" has a special priority in vi, I know, but this behavior is inconsistent and makes me sad and go back to nvim

[Chillee]

@kswope I'm confused. What do you expect to happen when you press ss? Do you expect it to simply ignore the s command?

[kswope]

@Chillee

That is exactly right, its not uncommon either, I think I saw it in a tutorial somewhere and got used to it, this is in my vimrc. I believe there's some kinda of timer, when I press s and wait a second it does its normal behavior, that is how jk and jj work as well, being common remappings of ESC

nnoremap ss :w" remap ss to save file

[qaraluch]

The same issue with OO and oo.

[jpoon]

I mentioned here (https://github.com/VSCodeVim/Vim/issues/2932#issuecomment-412747979), but we execute the first match (using the above example, we'd run s command immediately without assessing for any potential longer matches. What is vanilla vim's behaviour here?

[sobjornstad]

@jpoon: Basically, it waits:

• until the sequence of keys cannot be interpreted in any other way (i.e., there are no more longer mappings) – this command is then executed
• until the sequence of keys doesn't form any valid mapping – vim cancels the original sequence and starts a new sequence beginning with the first key that can't form a valid mapping (this behaves a little differently in insert mode, where the full sequence is then typed into the document)
• until about one second after the last keystroke – vim executes the command associated with the keystrokes you currently have

See the various timeout options for the full scoop and ways you can customize that. Anyone else please correct me, I probably missed or misinterpreted some details.

Thanks for identifying my leader issue as related -- interesting.

[jpoon]

In terms of what you defined:

until the sequence of keys cannot be interpreted in any other way (i.e., there are no more longer mappings) – this command is then executed until the sequence of keys doesn't form any valid mapping – vim cancels the original sequence and starts a new sequence beginning with the first key that can't form a valid mapping (this behaves a little differently in insert mode, where the full sequence is then typed into the document)

vscodevim should already be aligned with the above behaviour.

until about one second after the last keystroke – vim executes the command associated with the keystrokes you currently have

Here's where our implementations differ. At the moment, on that last keystroke, we execute whatever matches instead of waiting for a longer potential remap. I'm going to re-purpose this issue to track this point.

[autolyticus]

Was about to open a new issue for a related problem when I found this one.

I encountered this same problem when I attempted to remap mm to dd to have d be the "delete" operator and m be the "cut" operator. As a result of this, we cannot have a working mapping for mm or m* as long as the mapping for m exists.

[mauricecruz]

Recently migrated from Atom using vim-mode-plus. I remapped jj to <Esc> and noticed that a j always prints out first before getting removed and the mode changing.

Here's where our implementations differ. At the moment, on that last keystroke, we execute whatever matches instead of waiting for a longer potential remap. I'm going to re-purpose this issue to track this point.

That seems like a plausible explanation of what I'm experiencing. Is that what's going on or is there some type of configuration I'm missing?

[jpoon]

Nope, that would explain your experience with the momentary "j"

[mauricecruz]

What's the likelihood of this getting implemented in the short term?

I've noticed an increase in typos because of dangling j's in my code because the print out is included in the history buffer.

So when I undo something, I have to undo twice to get to the right undo position.

[istrupin]

The same issue with OO and oo.

Seeing the same behavior here -- wanted to remap those to insert a new line and go back to normal mode, but no such luck.