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

@davea1 commented on GitHub (Jul 20, 2020):

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.

@davea1 commented on GitHub (Jul 20, 2020): 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 <kbd>Ctrl</kbd>+<kbd>v</kbd> 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.

claunia commented

@jmoyers commented on GitHub (Aug 14, 2020):

My experience:

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

Asks:

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

@jmoyers commented on GitHub (Aug 14, 2020): **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

claunia commented

@DHowett commented on GitHub (Aug 14, 2020):

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.

@DHowett commented on GitHub (Aug 14, 2020): 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.

claunia commented

2026-01-31 01:18:15 +00:00

@jmoyers commented on GitHub (Aug 15, 2020):

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?

@jmoyers commented on GitHub (Aug 15, 2020): 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?

claunia commented

@DHowett commented on GitHub (Aug 15, 2020):

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?

@DHowett commented on GitHub (Aug 15, 2020): 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?

claunia commented

2026-01-31 01:18:15 +00:00

@jmoyers commented on GitHub (Aug 15, 2020):

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.

@jmoyers commented on GitHub (Aug 15, 2020): 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.

claunia commented

2026-01-31 01:18:15 +00:00

@d3x0r commented on GitHub (Nov 9, 2020):

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?).

@d3x0r commented on GitHub (Nov 9, 2020): 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?).

claunia commented

@zadjii-msft commented on GitHub (Nov 9, 2020):

@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!

@zadjii-msft commented on GitHub (Nov 9, 2020): @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!

claunia commented

@d3x0r commented on GitHub (Nov 9, 2020):

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

@d3x0r commented on GitHub (Nov 9, 2020): I will dig into it; I suspect it's maybe that they were set and are no longer set also...

claunia commented

@andreykaipov commented on GitHub (Dec 27, 2020):

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?

@andreykaipov commented on GitHub (Dec 27, 2020): 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](https://github.com/andreykaipov/home/blob/7d534e5df974de0615bbbfc20129a2dbd4e36e1b/.config/windows.terminal/settings.json#L65-L72), 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?

claunia commented

@d3x0r commented on GitHub (Dec 27, 2020):

@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)

@d3x0r commented on GitHub (Dec 27, 2020): @andreykaipov ``` json { "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)

claunia commented

@kushlendramishra commented on GitHub (Feb 19, 2021):

@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.

@kushlendramishra commented on GitHub (Feb 19, 2021): @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.

claunia commented

@zadjii-msft commented on GitHub (Feb 19, 2021):

@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

@zadjii-msft commented on GitHub (Feb 19, 2021): @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

claunia commented

@ghost commented on GitHub (Feb 19, 2021):

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.

@ghost commented on GitHub (Feb 19, 2021): 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.

claunia commented

@kushlendramishra commented on GitHub (Feb 21, 2021):

@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?

@kushlendramishra commented on GitHub (Feb 21, 2021): > @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?

claunia commented

@jtaseff-gfms commented on GitHub (Apr 20, 2021):

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" }

@jtaseff-gfms commented on GitHub (Apr 20, 2021): 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" } `

claunia commented

@d3x0r commented on GitHub (Apr 21, 2021):

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...

@d3x0r commented on GitHub (Apr 21, 2021): > 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...

claunia commented

@spencerharmon commented on GitHub (Apr 28, 2021):

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.

@spencerharmon commented on GitHub (Apr 28, 2021): 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.

claunia commented

@DHowett commented on GitHub (Apr 28, 2021):

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

@DHowett commented on GitHub (Apr 28, 2021): This configuration has not changed in 18 months and almost certainly does not flip itself randomly.

claunia commented

@gpvos commented on GitHub (May 10, 2021):

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.

@gpvos commented on GitHub (May 10, 2021): 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.

claunia commented

@spencerharmon commented on GitHub (Jun 1, 2021):

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.

@spencerharmon commented on GitHub (Jun 1, 2021): 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.

claunia commented

@jtaseff-gfms commented on GitHub (Jun 1, 2021):

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

@jtaseff-gfms commented on GitHub (Jun 1, 2021): > 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

claunia commented

@ghost commented on GitHub (Jun 5, 2021):

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.

@ghost commented on GitHub (Jun 5, 2021): 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.

claunia commented

@AndrewSav commented on GitHub (Jun 5, 2021):

@brianmingus2 why do you single out PowerShell? Windows terminal can be used with a plethora of shells/apps, do you suggest that it should detect what's running inside? Given that executables can be easily renamed it does not sound very practical.

@AndrewSav commented on GitHub (Jun 5, 2021): @brianmingus2 why do you single out PowerShell? Windows terminal can be used with a plethora of shells/apps, do you suggest that it should detect what's running inside? Given that executables can be easily renamed it does not sound very practical.

claunia commented

@ghost commented on GitHub (Jun 5, 2021):

Correct, in the case of WSL it should adopt the prime directive.

@ghost commented on GitHub (Jun 5, 2021): Correct, in the case of WSL it should adopt the prime directive.

claunia commented

@ghost commented on GitHub (Jun 5, 2021):

^^ As software engineers, lists are our bread and butter. We should not be afraid of making and maintaining lists.

@ghost commented on GitHub (Jun 5, 2021): ^^ As software engineers, lists are our bread and butter. We should not be afraid of making and maintaining lists.

claunia commented

@spencerharmon commented on GitHub (Jun 7, 2021):

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 commented on GitHub (Jun 7, 2021): 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.

claunia commented

@spencerharmon commented on GitHub (Jun 7, 2021):

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.

@spencerharmon commented on GitHub (Jun 7, 2021): 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.

claunia commented

@IAmIlliest commented on GitHub (Jun 14, 2021):

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...

@IAmIlliest commented on GitHub (Jun 14, 2021): 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...

claunia commented

@ghost commented on GitHub (Jun 14, 2021):

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

@ghost commented on GitHub (Jun 14, 2021): In Windows Terminal Preview I was able to delete the Ctrl+v paste binding under Settings > Actions

claunia commented

@spencerharmon commented on GitHub (Jul 16, 2021):

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 commented on GitHub (Jul 16, 2021): 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.

claunia commented

@spencerharmon commented on GitHub (Jul 16, 2021):

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

@spencerharmon commented on GitHub (Jul 16, 2021): This time, restarting WT resolved the incorrect behavior. That's not a very good outcome.

claunia commented

@spencerharmon commented on GitHub (Jul 16, 2021):

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.

@spencerharmon commented on GitHub (Jul 16, 2021): 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.

claunia commented

@Nimmidev commented on GitHub (Oct 20, 2021):

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

@Nimmidev commented on GitHub (Oct 20, 2021): For everyone that still has trouble with unbinding CTRL+V globally in windows-terminal: Put this into your `settings.json` under `actions`: ```json { "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: ```powershell Remove-PSReadLineKeyHandler -Chord "ctrl+v" Remove-PSReadLineKeyHandler -Chord "ctrl+v" -ViMode Command ```

claunia commented

@Tomicapo commented on GitHub (Mar 21, 2022):

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

@Tomicapo commented on GitHub (Mar 21, 2022): Hi. Sorry if it's not the correct place! Why can't we have "shift + insert" for pasting in wsl?

claunia commented

@zadjii-msft commented on GitHub (Mar 22, 2022):

@Tomicapo You're more than welcome to add

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

to your actions to enable pasting on shift+insert

@zadjii-msft commented on GitHub (Mar 22, 2022): @Tomicapo You're more than welcome to add ``` { "command": "paste", "keys": "shift+insert" }, ``` to your actions to enable pasting on <kbd>shift+insert</kbd>

claunia commented

@vadimkantorov commented on GitHub (Apr 29, 2022):

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

@vadimkantorov commented on GitHub (Apr 29, 2022): Again hit by this, I would argue that for WSL profiles, the default should disable Ctrl+V as Vim is very popular....

claunia commented

@xinloi commented on GitHub (Apr 3, 2023):

Hi,
I am also interested in this feature for SSH.

@xinloi commented on GitHub (Apr 3, 2023): Hi, I am also interested in this feature for SSH.

claunia commented

@pm100 commented on GitHub (Oct 27, 2023):

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 commented on GitHub (Oct 27, 2023): 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

claunia commented

@pm100 commented on GitHub (Oct 27, 2023):

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)

@pm100 commented on GitHub (Oct 27, 2023): 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)

claunia commented

@alex-jitbit commented on GitHub (Nov 22, 2023):

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

@alex-jitbit commented on GitHub (Nov 22, 2023): 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

claunia commented

@Hobart commented on GitHub (Mar 26, 2024):

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.

@Hobart commented on GitHub (Mar 26, 2024): > 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.

claunia commented

@daviddwlee84 commented on GitHub (Jul 26, 2024):

I found there are options in the Actions tab that can easily delete the key bindings

@daviddwlee84 commented on GitHub (Jul 26, 2024): I found there are options in the Actions tab that can easily delete the key bindings ![image](https://github.com/user-attachments/assets/63b9ec50-f11d-429e-951f-2abf297861f6)

claunia commented

@taiwork commented on GitHub (Aug 6, 2024):

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:

When text is selected, copy the text

When no text is selected, send the SIGINT signal to terminate an application

Ctrl+V:

When in vim insert mode, paste copied text

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?

https://github.com/microsoft/terminal/issues/5790#issuecomment-2252281727
To achieve the desired behavior, follow these steps after removing the <C-v> key binding as mentioned in the link above:

Open your .vimrc file.
Add the following line to remap <C-v> in insert mode to paste the copied text:

inoremap <C-v> <C-r>+

This will allow to paste copied text in insert mode while keeping its default behavior in normal mode.

@taiwork commented on GitHub (Aug 6, 2024): > 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? https://github.com/microsoft/terminal/issues/5790#issuecomment-2252281727 To achieve the desired behavior, follow these steps after removing the `<C-v>` key binding as mentioned in the link above: 1. Open your `.vimrc` file. 2. Add the following line to remap `<C-v>` in insert mode to paste the copied text: ```vim inoremap <C-v> <C-r>+ ``` This will allow <C-v> to paste copied text in insert mode while keeping its default behavior in normal mode.

claunia commented