Vim.exe can disable ctrl+v to paste in conhost, but not in Windows Terminal

[kasajian]

I map the Ctrl+V to Paste in Windows Terminal:
{
"command": "paste",
"keys": "ctrl+v"
},
to simulate what I can do in cmd.exe.

However, when I use the command-line version of vim, from cmd.exe, in Normal mode, if I hit "Ctrl+V", it correctly puts it into "Visual mode".
When I'm in cmd.exe outside of vim, just typing at the console, Ctrl+V will paste to the console as it's supposed to.

In Windows Terminal, with the above setting, Ctrl+V works from the console window, but in vim doesn't see the key-combination.

It would be good for Windows Terminal key bindings to only be in effect when it's typed at the console.

[elsaco]

@kasajian please use "crtl+alt+v" to enter visual mode when using vim and wt.

[WSLUser]

WT has a keybindings for both ctrl+shift+v and ctrl+v to paste. The latter is in the user settings so it can be removed easily by anybody having issues with something like using vim. I typically use ctrl+shift+v for muscle memory now to prevent issues with linux apps and works just fine with vim, just be sure you enter edit mode first as it can act alittle weird otherwise.

Agree with elsaco for entering vim visual mode.

[kasajian]

I appreciate the workarounds. But I think this is something that should be address in Windows Terminal. It can work since it does work in cmd.exe. One possible feature that can be a workaround is to allow mappings to be app specific, or console specific. In this case, the "ctr+v" i could to the console window only. Or alternatively, I could say that for ctrl+v, "exclude it for vim". That way, the user is free to create exclusions as the please.

[kasajian]

Does anyone have any thoughts on if this can ever be fixed? It's possible someone may be willing to work on it (maybe me), if there's agreement that this is worth fixing.

The issue to me is that I don't really feel like I, or others, should have to compromise when something very basic works under cmd.exe, but will not work in Windows Terminal. Maybe the solution is within vim. I don't know. But the current response is only talking about what can be done now -- there's no acknowledgment that this is in fact a problem.

Under cmd.exe, Ctrl+V works in the console window to paste text from the clipboard. I don't want to give that up.
But if I were to enable that in Windows Terminal, it takes that over for all apps, including vim. So then in vim, if I type Ctrl+V, Windows Terminal won't actually send that command to vim to do what vim is supposed to do. So effectively, if you map a key in Windows Terminal, no other console app running in Windows Terminal can ever use it.

If cmd.exe can do it -- so should Windows Terminal. One simpler feature is to allow the user map key bindings in Windows Terminal that are "app specific". So I can map Ctrl+V to copy globally, but locally for VIM, I can say "don't use the setting, but use 'default'" which causes Windows Terminal to ignore the default mapping in VIM's case.

[zadjii-msft]

I suppose in the fullness of time, this is maybe something that could get implemented. If we were being incredibly bold:

• We could have ConPTY tell the Terminal when QuickEdit was enabled/disabled by a client application
• We could have context-sensitive keybindings, that only apply in certain scenarios. I'm thinking different that profile-specific keybindings, more like "this is only active in the alt buffer"
• One of those pieces of context could be "This is only active when in QuickEdit mode".

It would be a lot of work. It's probably not impossible, but I'd reckon it's pretty far down the backlog.

The workarounds today would be limited to:

• Don't use Ctrl+v as a keybinding, only Ctrl+shift+v. Your muscle memory will have to change a little, but the actions would be consistent.
• Disable Ctrl+v as a keybinding, and use PowerShell as the shell. PowerShell itself actually listens for ^V itself, and manually pastes when it sees that. The muscle memory would obviously need to change a lot more, for using an entirely new shell.