search

microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
94.99k stars 8.22k forks source link

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

Open davea1 opened 4 years ago

davea1 commented 4 years ago

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 commented 4 years ago

This issue is somewhat related to: #5641

DHowett-MSFT commented 4 years ago

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

davea1 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

andreykaipov commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

gpvos commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

AndrewSav commented 3 years ago

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

ghost commented 3 years ago

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

ghost commented 3 years ago

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

spencerharmon commented 3 years ago

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 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

spencerharmon commented 3 years ago

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 3 years ago

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

spencerharmon commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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

zadjii-msft commented 2 years ago

@Tomicapo You're more than welcome to add

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

to your actions to enable pasting on shift+insert

vadimkantorov commented 2 years ago

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

xinloi commented 1 year ago

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

pm100 commented 10 months ago

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 10 months ago

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 commented 10 months ago

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 commented 5 months ago

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.

daviddwlee84 commented 1 month ago

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