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 https://github.com/microsoft/terminal/issues/5641#issuecomment-621186852

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 https://github.com/MicrosoftDocs/terminal/issues/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)

[kushlendramishra]

@andreykaipov Unbinding ctrl+c seems to have worked as you specified, but ctrl+v is still pasting. Can you please show where this has to be put in settings.json? I have tried to put the "keybindings" (and also "actions") in the global settings and the "defaults" part of "profiles but to no effect.

[zadjii-msft]

@kushlendramishra What shell are you using? I believe powershell has special handling for Ctrl+V to also manually paste on Ctrl+V itself, even when it's unbound in the Terminal

[ghost]

Unbinding Ctrl+V works with WSL, however this also breaks pasting from the clipboard history with Win+V, as it tries to send Ctrl+V.

[kushlendramishra]

@kushlendramishra What shell are you using? I believe powershell has special handling for Ctrl+V to also manually paste on Ctrl+V itself, even when it's unbound in the Terminal

I use the PwerShell. I use it to ssh to a linux remote and work on that. So what should I do in this case?

[jtaseff-gfms]

I finally managed to unbind paste... able to get visual block mode in vim over ssh. Weirdly don't have issues with ctrl+c passing through while copy is still mapped.

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

[d3x0r]

I finally managed to unbind paste... able to get visual block mode in vim over ssh. Weirdly don't have issues with ctrl+c passing through while copy is still mapped.

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

was going to say 'I think you want 'ctrl+shift+v' to get ctrl-shift-v to work... you had only specific ctrl+v... but now with your remaining comment; seems you should just have "ctrl+c" also...

[spencerharmon]

Wow. I dug around in elisp code on my remote machine trying to figure out who enabled CUA mode. Microsoft devs, please don't randomly change my configuration. It's not the first time opening the file in my case. I already had to modify this to set bellStyle to none and cursorShape to filledBox. Thanks @jmoyers for the explanation.

[DHowett]

This configuration has not changed in 18 months and almost certainly does not flip itself randomly.

[gpvos]

I hope this is related enough to mention in this issue rather than a new one, but what annoys me (independent of profile) is that shift+ctrl+c, if nothing has been selected, sends an interrupt. If I had wanted to interrupt, I would have typed ctrl+c without shift. Inadvertently interrupting a process can be very disruptive to my workflow. In my memory, this is a new behaviour since a few months, but I might be wrong. So I would like an option to the "copy" action (or a separate action) to NOT default to interrupt if nothing has been selected; in that case, just do nothing.

2021-05-28: Edit: I have created a new issue for this now.

[spencerharmon]

Just thought I'd chime in again to say that this behavior randomly changed again (but not my profile.json). Without explicitly defining the bindings, ctrl+shift+c started sending SIGINT. Very frustrating.

[jtaseff-gfms]

Just thought I'd chime in again to say that this behavior randomly changed again (but not my profile.json). Without explicitly defining the bindings, ctrl+shift+c started sending SIGINT. Very frustrating.

Just yesterday one of my devices decided to stop pasting on right click, no clue what changed or how to get it back. Now it does some combination of messing up the last few minutes of typing

[ghost]

For Windows Terminal, if you are in a PowerShell terminal the correct behavior is for Ctrl+v to paste from the clipboard. However, in a WSL terminal this is INCORRECT behavior; the shortcut should be delegated / passed through.