Extensions intercept keystrokes pressed in Debug Console

[johnfn]

• VSCode Version: 1.5.0-insiders
• OS Version: OSX 10.10.5 Yosemite

Steps to Reproduce:

1. Install VSCodeVim or another extension that intercepts common keystrokes while editing code.
2. Begin debugging code.
3. Hit a breakpoint.
4. Open up the debug console and click on the text box used for evaluating expressions.
5. Press a key that VSCodeVim or another extension would typically intercept while editing the document.
6. The text will not show up in the expression evaluation text box. Instead, it will be sent to the extension.

This does not happen in 1.4.0; it seems to have been introduced in the insiders build.

[jrieken]

@alexandrudima fyi

[sandy081]

I am able to reproduce this with our sample Vim extension.

[johnfn]

The bug has evolved: now I have fully-featured Vim keybindings inside my debug console. This is actually kind of awesome. But not really expected.

[sandy081]

Yes this is expected. Debug console is made from editor now and hence in Vim mode it will be also behave same.

[johnfn]

How is this expected behavior? The debug console will appear broken for anyone who uses the Vim plugin. It should at least be under a flag.

[sandy081]

@alexandrudima and @isidorn Assigning this back to you so that you can provide the discussed solution for this.

Thanks

[alexdima]

@johnfn The state we will ship with in August is that the debug repl will be vim-enabled (just another regular TextEditor as far as extensions are concerned). This makes it possible to use vim-style keybindings in the repl:

[johnfn]

@alexandrudima I completely understand that, I just think it's unexpected and surprising behavior. I'm particularly concerned that users will believe that VSCodeVim has broken the debugging console, because they won't realize they have to go into insert mode first to start typing.

It took me a while to realize this, and I'm one of the authors of the plugin!

Again, I think that this behavior should be under a flag rather than default behavior.

[alexdima]

We are in a position (in the core) where we can block extensions from seeing this editor, but perhaps it is best to expose this editor and allow each extension to do as it pleases. For example, there could be an extension that contributes useful text commands in general, and end users would want them available in the repl (since the repl now uses an editor and no longer an input as its implementation).

E.g. I configure my keybindings to choose a certain style of word navigation (always stop at word ends), or perhaps I use a cool extension that contributes a text edit command. We thought it is better to expose this editor to the extension host and ... well ... see if it is appreciated or not.

That being said, I don't have a strong feeling in any direction. But "hiding" the editor in there will have some consequences: e.g. only default core keybindings, only default core commands and definitely not something behind a flag that can mutate at runtime. Please also note that with the current implementation it is possible to implement the flag you suggest in the vim extension side.

[johnfn]

Hmm... interesting. I'll float the idea to the vscodevim community and see what they think.

I've opened up a pseudo poll here: https://github.com/VSCodeVim/Vim/issues/666

[rebornix]

It feels weird that only Debug Console pane supports Vim key bindings besides the core editor IMHO. My current feeling is anything but the core editor is supposed to follow Code's bindings.

I'm not against current behavior but if Debug Console supports Vim bindings, people should be able to navigate to the pane by Vim command ctrl-w j, similar to navigating between editor groups. Do we already have this kind of support @alexandrudima ? Once we support editor groups both vertically and horizontally, the debugging pane is almost the same as horizontal editor group.

Besides, to make Vim users really feel at home, we may want to have Vim key bindings in Explorer Panel as well.

[johnfn]

@rebornix has a good point - you certainly wouldn't expect Vim shortcuts to work in the search panel, or the go-to-file panel, or the git commit message textbox. I think this is why it feels unexpected for them to work in the debug console.

[alexdima]

@rebornix @johnfn After discussing in today's standup, given the upcoming release and the risk of changing the way this works in core, it would be great if you could add a workaround in the vim extension:

• the debug repl editor always has the document with the uri debug:input
• you could potentially filter on this uri and ignore/delegate back the commands (i.e. call back default:type from the type command, etc.)
• otherwise you could automatically go into insert mode when the editor that has this document becomes active. In this way end users could immediately type in the repl and by pressing Escape they could go to vim normal mode in it.

@rebornix assigning to you to get your opinion on this

[rebornix]

@alexandrudima both sound good to me. I'll go with the first one and see if there is any catch or user feedback. If there is a workaround, then it is not a problem any more.

[rebornix]

@alexandrudima I filter debug:input from input command and the typing now works perfect but we have issues with additional keybindings like ctrl/alt/cmd/backspace/esc..., since they are not passed to default:input directly, the way to customize its behavior is adding it to keybindings. So in this case, we have to filter out debug:input for keybindings as well.

You can take a look at https://github.com/VSCodeVim/Vim/pull/723 and it shows how we can filter out debug:input in keybindings dirty but quick. It works but the catch is, each time we add a new keybinding, we have to add this !vim.debugInput check. Besides, editorTextFocus is now confusing as it's not just editor, it includes debugRepl. I think this will impact users who customize his own keybindings with when clause. It's likely a bigger issue, right ?

[alexdima]

You're right, all the keybindings are impacted, I'm sorry I didn't realize this. The repl editor already has the context key inDebugRepl so you can use that instead of maintaining your own key. I am sorry for 1.5.0 this workaround will be necessary on your side.

fyi @egamma Maybe we can use some time in September to revisit if we can correctly hide the repl from the extension host.

[isidorn]

Ping @rebornix to fix this in the vim extensino, pushing it out to october since it is independent of vscode releases

[rebornix]

@isidorn we already had a workaround in Vim so it's not a Vim blocker. It's up to Alex when to implement.

[isidorn]

@rebornix so this should be assigned to @alexandrudima Removing important since there is a workaround, removing mileston so @alexandrudima can decide

[adamhewitt627]

I'm seeing similar behavior as this when focus is in the Source Control Message field in at least 1.11.1, though I know it was in 1.10 as well. I have the Visual Studio Keymap extension, which adds a "Ctrl+backspace" mapping. Using that shortcut in the SCM field removes code from the editor window.

[isidorn]

Fixed via https://github.com/Microsoft/vscode/commit/f470ce19e7afb450a7bad0aea47281b5817d094b

@johnfn @Chillee @rebornix you can remove the wokraround in VIM which was excluding the debug repl input here https://github.com/VSCodeVim/Vim/blob/master/extension.ts#L303