VsVim bindings affect standard keyboard shortcuts in non-text-editor windows

[ricksladkey]

The following standard keyboard shortcuts no longer work in non-text-editor windows (e.g. Find Results, Output, Immediate) when set to "handle with VsVim":

• Ctrl+Home
• Ctrl+Left
• Ctrl+Right
• Shift+Left
• Shift+Right

In fact, it's worse than not working because Shift+Left in, say, the immediate window, appears to be bound to something bizarre that is like Ctrl+Tab but for sub-controls, maybe panels. It is possible to cycle the keyboard focus to many of the controls all over the screen.

Here a screenshot. Notice the dotted border to the left of the text that now has the keyboard focus:

[ricksladkey]

More testing show that even with VsVim disabled the problem persists so the issue is just the unbinding itself.

This appears to be the problematic binding for Shift+Left:

1496a755-94de-11d0-8c3f-00c04fc2aae2!8!Edit.CharLeftExtend!Text Editor::Shift+Left Arrow

restore just that one by hand fixed the immediate window.

[jaredpar]

This is a duplicate of #925.

There are certain key combinations that Visual Studio registers on a global level. When VsVim takes over those bindings it disables it for all windows. This is an unfortunate effect of how Visual Studio handles key bindings. Most commands are registered globally and not specific to window type / content type. Hence taking it over anywhere takes it over everywhere.

I've been working with the VS guys to find a cleaner way of handling this. Unfortunately it's not as simple as switching them on and off whenever VsVim has focus. Every change, literally every single change to key bindings, causes multiple disk hits and visibly impacts perf in some scenarios. It's highly frustrating.

[ricksladkey]

This is probably a silly idea but...

I did a little experimenting and a VSPackage with command support allows us to create commands like Edit.ShiftLeft that can be bound to a Shift+Left shortcut in the Text Editor (non-global) context. This command does indeed fire in the editor and in the immediate window. If we can tell the difference, we can either invoke our own implementation or just foward it to the standard command Edit.CharLeftExtend.

This would require no rebinding when the focus changes and if it wors, the only disadvantages are that it's clumsy and that it freezes the users binding at the time the new bindings are installed. Even in that situation, the user can say:

• Handle with Visual Studio
• Change the Key Binding for Visual Studio
• Handle with VsVim

to get around the freezing problem.

[jaredpar]

That's the general approach the VS team had recommended I take. Essentially register my own commands, give them higher priorities and go from there. Note that this also allows for a path to VsVim handling key bindings that use Alt. It's not possible today because of how Visual Studio preemptively steals those key strokes

It gets a bit more complex though because of user customization. Consider the case where the user themselves removes the binding for Edit.CharLeftExtend. In that case if we're in a window that doesn't handle Edit.ShiftLeft we shouldn't forward to Edit.CharLeftExtend. We have to do look up on the fly to find out what command we should be mapping to. This could be cached though.

Also the support needs to be a bit more general. Instead of special casing Edit.ShiftLeft we need to special case any time that a command binding, or key mapping, conflicts with a registered command. When you trace it out we end up needing dynamic key bindings vs. a fixed set of static ones.

I've done experiments around this in the past and it does mostly pan out. It's unfortunately a good deal of work though because of the insane ways in which Visual Studio special cases keyboard handling. I'm still hoping to get this done (for Alt if nothing else).

[jaredpar]

In the early days of VsVim i spent more time dealing with key input issues than practically anything else. Visual Studio makes trapping keyboard input in a realible fashion extremely difficult. :(