Vscode: Multiple extensions registering the 'type' command

[wmaurer]

• VSCode Version: 1.5.3
• OS Version: Windows 10

Steps to Reproduce:

1. Install and enable VSCodeVim and vscode-jumpy
2. Open a file with text
3. Run the command Jumpy Word Mode. Two letter decorations should appear at the start of each word
4. Type in the two letter code for that word. Jumpy functionality should enact a 'Jump' to the cursor position of that decorator.
5. It doesn't work :-( The keystrokes are being processed by VSCodeVim, not Jumpy.

I am the author of vscode-jumpy (repo). A user has reported that Jumpy does not work in combination with VSCodeVim: wmaurer/vscode-jumpy#1.

It seems that both extensions are doing a registerCommand('type'), but VSCodeVim seems to take priority over vscode-jumpy. Is there are way to manage which extension has priority, so that it can receive and process the keystrokes?
Ideally I want to Jumpy to receive and process the next two keystrokes after enabling Jumpy Word Mode, but then let the rest of the keystrokes forward to VSCodeVim.

[alexdima]

We added registerCommand("type") especially to enable vim mode to be implemented from an extension. We didn't want to bake vim mode in the core, and there can be only one handler. We never considered typing being something collaborative (in this case between vscode-jumpy and VSCodeVim). Today, the last one wins.

[samdesota]

Could this be changed to something like ahandleKeys function? Something like:

...

vscode.commands.registerCommand("start-mode", () => {
   // Latest attached handler receives the keys first.
   const subscription = vscode.handleKeys((evt) => {
     // event will bubble to the next handler if you don't cancel
     evt.stopPropagation()
   })   

   // End subscription to return the key priority to the previous holder.
   setTimeout(() => subscription.unsubscribe(), 3000)
})

Would really like to use vscode-jumpy, I imagine this would be fairly easy to implement?

[staltz]

For what it's worth, Atom is able to handle both jumpy and vim emulation (and probably more).

[samdesota]

@alexandrudima I'd really like this feature, if you would point me in the right direction in the source and discuss a pull request I'd be glad to work on it.

[lucax88x]

I have the same precise issue by using my extension (codeacejumper)

[aratakokubun]

I would like to turn off vim keybinding while activating jumpy line or word mode.
Is there any possible solution to do this? (ex: create a extension or set keymap)

[Shinikami]

Hey, all.
May we have this issue updated, please?

[wd]

It's has been 2 years, still can't get emacs-keymap work with ace-jump ext, does anyone have solution about this issue ?

[thieman]

If my reading of registerCommand is right, it already seems to implement the stack-like behavior we'd need for an extension to temporarily claim the type handler and then return it to the previous claimant (the Ace Jump usecase). https://github.com/Microsoft/vscode/blob/v1.19.3/src/vs/platform/commands/test/commands.test.ts#L25

@alexandrudima am I misunderstanding anything there?

I think there is a separate use case worth discussing though, which is extensions that want to be notified when typing happens but do not need exclusive control over changes to the output buffer. These might be well-served by an onDidType event or similar, which I don't think is provided currently. Thoughts on that, as well?

edit: I'm actually seeing references to an onDidType event that I didn't see in vscode.d.ts, I'll have to see if I can get to that

[Domiii]

I like @thieman's ideas, especially (2):

1. Change commands to execute the entire (already existing) stack of event handlers instead of only the top
   
   
   
   • Con: This is likely going to be a breaking change, since currently, type command handlers pass the ball by invoking the default:type command instead of communicating their intentions back to the caller
   
   
2. Expose the onWillType and onDidType events to the Extension API
   
   
   
   • Pro: Its a very basic functionality to have for editor extensions
   
   
   • Also, here I have a question: I am guessing that such event handlers would use the same model of communication as the command engine, so it would probably not improve performance? (Performance problems have been reported many times, e.g. #65876 #75627)