Method to suppress the default CTRL+C/CTRL+V mapping specifically for WSL; profile-specific keybindings?

[davea1]

Editor's Note (@DHowett-MSFT): This may be a good place to track profile-specific keybindings?

With the classic Windows terminal, Ctrl+c and Ctrl+v can be used for copy and paste when working within a Windows shell just as I would expect/prefer. However, when using WSL, this is typically not the case and those keys are available for use by Linux applications such as Vim.

How can I replicate this same behavior with the new Windows Terminal?

Background:
When working specifically within the WSL environment, Vim is my primary editor and the presence of any Ctrl+v mapping effectively blocks the use of blockwise Visual mode (http://vimdoc.sourceforge.net/htmldoc/visual.html#CTRL-V).

Removal of these mappings in a global scope is undesirable since I do not want to lose the use of Ctrl+c and Ctrl+v for copy and paste when working within a Windows shell.

I realize that similar issues have been discussed at length and that any choice here is somewhat of a compromise, but the ability to replicate the current behavior of the classic Windows terminal in this regard is a tradeoff that I find acceptable/desirable.

[davea1]

This issue is somewhat related to: #5641

[DHowett-MSFT]

Maybe what we need is profile-specific keybindings. I'm surprised we don't have a workitem for that.

[davea1]

@DHowett-MSFT This was actually what I had considered as the most obvious solution to this issue, but simply wanted to leave it up to the developers to choose whatever path they were the most comfortable with. Thanks!

[adamjstewart]

For the vim Ctrl+V use case, would it be possible to do something similar to what we do for Ctrl+C?

Proposed Behavior

Ctrl+C:

1. When text is selected, copy the text
2. When no text is selected, send the SIGINT signal to terminate an application

Ctrl+V:

1. When in vim insert mode, paste copied text
2. When in vim normal mode, use blockwise visual mode

Possible Workaround

Is there any way to remap the behavior of Ctrl+V in my .vimrc to produce the desired effect right now?

[motosir]

For the vim Ctrl+V use case, would it be possible to do something similar to what we do for Ctrl+C?

Proposed Behavior

Ctrl+C:

1. When _text is selected_, copy the text

2. When _no text is selected_, send the SIGINT signal to terminate an application

Ctrl+V:

1. When in vim _insert_ mode, paste copied text

2. When in vim _normal_ mode, use blockwise visual mode

Possible Workaround

Is there any way to remap the behavior of Ctrl+V in my .vimrc to produce the desired effect right now?

is it possible for terminal to detect if vim is running/current vim mode?

[DHowett]

Not generally, no. We would only be able to detect instances of vim.exe and miss all instances of vim in WSL or over SSH (because you can’t inspect the processes inside a virtual machine or on a remote system just through SSH)

[adamjstewart]

Is there any way to remap the behavior of Ctrl+V in my .vimrc to produce the desired effect right now?

I ended up remapping paste to V because I don't use normal visual mode. Place the following in your .vimrc:

nnoremap v <c-v>                                                                                                                          

Replace v with whatever key you want to use instead.

[davea1]

I have found that making use of the Vim <leader> key feature is a great method for defining additional non-breaking key combinations.

Example workaround for Ctrl+v issue within Vim by utilizing the <leader> key:

nnoremap <Leader>v <c-v>

Hopefully, profile-specific keybindings or some other solution to this issue will be implemented soon.

[jmoyers]

My experience:

1. I learned ctrl-shift-c/v, muscle memory adjusted after a day or two. Compatible with foreground sigint and vim. Rejoice.
2. Vim visual mode broke "randomly" and instead ctrl-v now pastes from system clipboard.
3. It happened to be the same day I installed tmux. I detached tmux. I finally uninstalled tmux. Still have the issue.
4. After living with it for a day or two, I think to look in the Microsoft Terminal settings file
5. Find the new keybinds apparently automatically added when I opened it briefly two days ago. Despair. Delete.

Asks:

1. Don't automatically change settings when opening a file for the first time
2. Don't break vim with default settings

[DHowett]

I'm confused about this. Terminal doesn't insert key bindings into your settings -- once your settings file is created (at first launch), we aren't going to add new key bindings.

[jmoyers]

From settings.json:

// Copy and paste are bound to Ctrl+Shift+C and Ctrl+Shift+V in your defaults.json.
// These two lines additionally bind them to Ctrl+C and Ctrl+V.
// To learn more about selection, visit https://aka.ms/terminal-selection

I deleted the lines following this, so I don't have reference to them. But they bound copy and paste to ctrl-c and ctrl-v.

Prior to clicking Settings, ctrl-v did not paste. Vim visual mode worked.

After the first time I clicked "Settings" from the menu (down chevron), ctrl-v then became paste, vim visual mode broke. I did not understand what happened. I came across a comment in another issue that I can't seem to find that said this was intentional as a compromise. I'll try to find it.

Maybe I encountered a bug or terminal upgraded in some way to change settings from one day to the next (maybe I got a new build automatically, I have no idea).

Edit: here is the thread #5641 (comment)

Ctrl+C/Ctrl+V are now listed in new user's settings.json file when they create a new settings file.
If they don't like them, it's trivial to just delete them from the file.
Ctrl+Shift+C/Ctrl+Shift+V will still work if the user deletes the Ctrl+C/Ctrl+V bindings from their settings.json

Clearly its a sore subject for people working on the project. All the settings are there, and I was able to fix it after I actually figured out what happened - great! The user experience part was weird and did not make sense, and sounds like it wasn't intended?

[DHowett]

Wow, that's definitely not supposed to happen. The user settings template is only supposed to be stomped down on disk if your settings file is nonexistent or empty. Did you lose any other settings?

We've gotten a couple sporadic reports of settings being nuked on save (!), but we've never had enough to go on. If I had to do some psychic debugging, I might guess that an editor locks the file very briefly when opening, and creates a swap/temp file. The creation of that file forces Terminal to re-scan the directory and when it fails to open the file (we should audit our sharing mode!) it declares all is lost and recreates it?

Complete guess, but it could explain settings disappearing when you open them in an editor. Which editor are you using?

[jmoyers]

I hadn't ever opened it before, so I was stock settings. vscode was the editor.

Probably a more mundane explanation. It sounds like I had a misunderstanding about the defaults. If ctrl-v defaults to paste now, I guess there is a non-zero chance that I just hadn't used ctrl-v in vim+microsoft terminal since it changed. I switch back and forth between vscode/vim mac/windows/linux frequently and I was on the insider's build early on.

Sorry about that, disregard.

[d3x0r]

how do I disable ctrl+c and ctrl+v all together? I commented them out in settings.json, but now they just don't work at all; well that's not true, they fail in the keyboard handler and prevent further keyboard input for 1.5 seconds (1?).

[zadjii-msft]

@d3x0r What the heck - that's very unexpected. If they're not in your settings.json, then the Terminal won't be handling them, they should be going straight to the shell. Would you mind filing a separate issue so we could follow-up and investigate to see what's wrong? Thanks!

[d3x0r]

I will dig into it; I suspect it's maybe that they were set and are no longer set also...

[andreykaipov]

I added the following to my keybindings and vertical selection worked fine again:

{ "command": "unbound", "keys": "ctrl+v" }

I didn't have this keybinding in my Windows Terminal settings back in June, so I guess something changed in between that time (or maybe I just never update my software).

I think the larger issue is this functionality is almost now undocumented, detailed in the following issue MicrosoftDocs/terminal#211. Who knows what else is now undocumented?

[d3x0r]

@andreykaipov

    {
      "command": "unbound",
      "keys": "ctrl+c"
    },
    {
      "command": "unbound",
      "keys": "ctrl+v"
    },

seems to work - but I haven't been using terminal because lack of mouse input (I use FAR Manager as a shell on top of the command shell)

[spencerharmon]

Back again with new behavior. Now, I have explicitly set:

    "actions": 
    [
        // Copy and paste are bound to Ctrl+Shift+C and Ctrl+Shift+V in your defaults.json.
        // These two lines additionally bind them to Ctrl+C and Ctrl+V.
        // To learn more about selection, visit https://aka.ms/terminal-selection
        { "command": "paste", "keys": "ctrl+shift+v" },
        { "command": "copy", "keys": "ctrl+shift+c" },

This used to do what you'd expect (copy with ctrl+shift+c and paste with ctrl+shift+v). However, after a reboot I ran into the pinned error about can't find whatever font so I set that explicitly to one that works in the json file (probably irrelevant). Now, when I press ctrl+shift+c OR ctrl+c, it sends SIGINT. I can copy and paste with right-click still. I see yall catch a lot of flak for this and I'm sorry that's the case. This happens to be the best/most configurable terminal I've found for windows, even with this sometimes-works-sometimes-not quirk. Sending good vibes your way and hoping for a fix/workaround.

[spencerharmon]

Well.. You know what? I removed the relevant lines above, saved, added them back, saved again, and it works! Hopefully that information will help determine what went wrong.

[IAmIlliest]

Just a note on this, make sure you don't have other things interfering with the clipboard that are confounding your testing, as it might not be Windows Terminal that is at fault.

I was trying to bugger off the Ctrl+V and Ctrl+C bindings for Powershell 7, and couldn't work out why it was still pasting with them despite disabling them in Windows Terminal settings. Some further digging, after some initial swearing at WT, made me think that the PSReadLine module that I have installed within PS 7 could be the culprit, as it does indeed have it's own key bindings for copy and paste:
https://github.com/PowerShell/PSReadLine
(That page has commands for listing PSReadLine's key bindings).

If I fire up a different shell within Windows Terminal like CMD or a terminal version of nvim, it does indeed appear that Ctrl+C and Ctrl+V have been unbound from copy and paste by Windows Terminal itself. So just be wary of co-conspirators when it comes to key bindings...

[ghost]

In Windows Terminal Preview I was able to delete the Ctrl+v paste binding under Settings > Actions

[spencerharmon]

Back again. WT started sending sigint even with { "command": "copy", "keys": "ctrl+shift+c" }. I didn't change my config. The workaround above isn't working this time.

[spencerharmon]

This time, restarting WT resolved the incorrect behavior. That's not a very good outcome.

[spencerharmon]

Well never mind, it's doing the other thing again. Is there anything I can provide to help yall debug this? Intermittent bugs like this are hard. I'm not sure how I can help you reproduce the error.

[Nimmidev]

For everyone that still has trouble with unbinding CTRL+V globally in windows-terminal:

Put this into your settings.json under actions:

{
    "command": "unbound",
    "keys": "ctrl+v"
}

This will unbind CTRL+V for the terminal itself BUT it still works in powershell. This is because PSReadLine is handling the keyboard shortcut. So if you have this problem you need to remove the binding for it:

Remove-PSReadLineKeyHandler -Chord "ctrl+v"
Remove-PSReadLineKeyHandler -Chord "ctrl+v" -ViMode Command

[Tomicapo]

Hi. Sorry if it's not the correct place!
Why can't we have "shift + insert" for pasting in wsl?

[zadjii-msft]

@Tomicapo You're more than welcome to add

{ "command": "paste", "keys": "shift+insert" },

to your actions to enable pasting on shift+insert

[vadimkantorov]

Again hit by this, I would argue that for WSL profiles, the default should disable Ctrl+V as Vim is very popular....

[pm100]

its not just WSL, I have a text mode app that wants to receive the ctrl-v key stroke. It has its own idea for what that means

[pm100]

shouldnt it be that if ENABLE_PROCESSED_INPUT is off then ctrl-v should be ignored? Or could we have another mode bit for paste (ENABLE_PASTE)

[alex-jitbit]

Actually, if there was a simple method to send Ctrl + V to the app just once it would be enough.

My use-case: I use "micro" editor via ssh. And copy-pasting in it is a huge pain in Windows terminal, because it intercepts my input.

PS. disabling the default "Ctrl+V" helps, but offering the above option would still be nice

[Hobart]

Actually, if there was a simple method to send Ctrl + V to the app just once it would be enough.

Using Windows Terminal to run a Cygwin bash shell runs into this problem, the default 'lnext' (literal next character) tty setting is Ctrl-V, which lets you e.g. put control characters into regexps you're typing instead of backslash escapes.