Include Ctrl+C, Ctrl+V keybindings by default #4254

@KirillOsenkov commented on GitHub (Oct 4, 2019):

cmd.exe didn't support these for years and finally added them quite recently. Even more puzzling to have these missing in the new one.

@KirillOsenkov commented on GitHub (Oct 4, 2019): cmd.exe didn't support these for years and finally added them quite recently. Even more puzzling to have these missing in the new one.

claunia commented

@ealsur commented on GitHub (Oct 4, 2019):

Copy and Paste was added in 0.3, if you installed 0.3 (or later), they were there by default. If you upgraded to 0.3, you needed to add them manually: https://devblogs.microsoft.com/commandline/windows-terminal-preview-v0-3-release/

@ealsur commented on GitHub (Oct 4, 2019): Copy and Paste was added in 0.3, if you installed 0.3 (or later), they were there by default. If you upgraded to 0.3, you needed to add them manually: https://devblogs.microsoft.com/commandline/windows-terminal-preview-v0-3-release/ ![image](https://user-images.githubusercontent.com/1633401/66232216-34b45c00-e69d-11e9-83b1-7ed2e467b6c5.png)

claunia commented

@pedroreys commented on GitHub (Oct 4, 2019):

For the curious, here is the PR where they added the default keybindings for copy and paste and they discuss the challenges of using Ctrl+C by default.

There is also #2285 that has extensive discussion about using Ctrl+C for copy vs emitting SIGINT.

@pedroreys commented on GitHub (Oct 4, 2019): For the curious, [here is the PR](https://github.com/microsoft/terminal/pull/1093) where they added the default keybindings for copy and paste and they discuss the challenges of using `Ctrl+C` by default. There is also #2285 that has extensive discussion about using Ctrl+C for copy vs emitting SIGINT.

claunia commented

@bradwilson commented on GitHub (Oct 4, 2019):

Please don't do this. Ctrl+C already has meaning inside terminals that long outdates copy/paste.

@bradwilson commented on GitHub (Oct 4, 2019): Please don't do this. Ctrl+C already has meaning inside terminals that long outdates copy/paste.

claunia commented

@DHowett-MSFT commented on GitHub (Oct 4, 2019):

Even more puzzling to have these missing in the new one.

Please don't do this. Ctrl+C already has meaning inside terminals that long outdates copy/paste.

This is a delightful vignette about why we have rebindable key actions, and why we don't want to be prescriptive with user experience where "terminal input" is concerned.

@DHowett-MSFT commented on GitHub (Oct 4, 2019): > Even more puzzling to have these missing in the new one. > Please don't do this. Ctrl+C already has meaning inside terminals that long outdates copy/paste. This is a delightful vignette about why we have rebindable key actions, and why we don't want to be prescriptive with user experience where "terminal input" is concerned.

claunia commented

@DHowett-MSFT commented on GitHub (Oct 8, 2019):

We can 100% bind Ctrl+C by default, now that we have support for passing through bindings that didn't trigger an action. We can 100% not bind Ctrl+V by default.

@DHowett-MSFT commented on GitHub (Oct 8, 2019): We can 100% bind <kbd>Ctrl+C</kbd> by default, now that we have support for passing through bindings that didn't trigger an action. We can **100% not** bind <kbd>Ctrl+V</kbd> by default.

claunia commented

@KirillOsenkov commented on GitHub (Oct 8, 2019):

I know Ctrl+C cancels the current execution, but what does Ctrl+V do? Out of curiosity.

@KirillOsenkov commented on GitHub (Oct 8, 2019): I know `Ctrl+C` cancels the current execution, but what does `Ctrl+V` do? Out of curiosity.

claunia commented

@bradwilson commented on GitHub (Oct 8, 2019):

@KirillOsenkov https://superuser.com/a/421468

@bradwilson commented on GitHub (Oct 8, 2019): @KirillOsenkov https://superuser.com/a/421468

claunia commented

@sgreenmsft commented on GitHub (Oct 10, 2019):

My (admittedly uneducated) guess is the percentage of users expecting Ctrl+V to result in paste is substantially larger than the percentage of users expecting Ctrl+V to result in "verbatim insert mode."

@sgreenmsft commented on GitHub (Oct 10, 2019): My (admittedly uneducated) guess is the percentage of users expecting Ctrl+V to result in paste is substantially larger than the percentage of users expecting Ctrl+V to result in "verbatim insert mode."

claunia commented

@impguard commented on GitHub (Nov 7, 2019):

@sgreenmsft

To be honest, for users used to using Terminal from Linux, Ubuntu, OSX, etc. I don't expect ctrl-V to paste. And seeing how a lot of the purpose of terminal is geared in that direction (to finally have Windows be able to start having a culture around working in the terminal instead of in GUI apps, catering towards those users seems preferable).

@impguard commented on GitHub (Nov 7, 2019): @sgreenmsft To be honest, for users used to using Terminal from Linux, Ubuntu, OSX, etc. I don't expect ctrl-V to paste. And seeing how a lot of the purpose of terminal is geared in that direction (to finally have Windows be able to start having a culture around working in the terminal instead of in GUI apps, catering towards those users seems preferable).

claunia commented

@sgreenmsft commented on GitHub (Nov 7, 2019):

@impguard
I honestly don't know how frequently verbatim insert mode is used by folks in linux/osx. My uneducated guess is "very infrequently." On the other hand, I suspect Ctrl+V is used quite frequently by folks familiar with cmd.exe and PowerShell. If my uneducated assumptions are accurate, then having Ctrl+V perform paste makes the experience significantly better for Windows-background users at minimal cost to Linux/OSX-background users.

@sgreenmsft commented on GitHub (Nov 7, 2019): @impguard I honestly don't know how frequently verbatim insert mode is used by folks in linux/osx. My uneducated guess is "very infrequently." On the other hand, I suspect Ctrl+V is used quite frequently by folks familiar with cmd.exe and PowerShell. If my uneducated assumptions are accurate, then having Ctrl+V perform paste makes the experience significantly better for Windows-background users at minimal cost to Linux/OSX-background users.

claunia commented

@durack1 commented on GitHub (Nov 24, 2019):

I am new to Microsoft terminal (v0.6.2951.0) and am starting to warm up to the idea of having access to powershell, cmd, ubuntu/wsl and azure cloud shell baked directly into a native Windows 10 app.

BUT, I was pulling my hair out today trying to copy the contents of a Ubuntu console, and would have assumed this functionality was baked in by default to a modern Win10 app. I acknowledge the ctrl-c issues above, but why not enable the copy functionality through a right mouse click, like that implemented in the more modern cmd versions? If you open cmd using Windows terminal there is no right click options enabled, whereas using the old cmd you get:

It'd be great if a future version of Windows Terminal baked this in by default across all shells - it's really useful to have

@durack1 commented on GitHub (Nov 24, 2019): I am new to Microsoft terminal (v0.6.2951.0) and am starting to warm up to the idea of having access to powershell, cmd, ubuntu/wsl and azure cloud shell baked directly into a native Windows 10 app. BUT, I was pulling my hair out today trying to copy the contents of a Ubuntu console, and would have assumed this functionality was baked in by default to a modern Win10 app. I acknowledge the ctrl-c issues above, but why not enable the copy functionality through a right mouse click, like that implemented in the more modern cmd versions? If you open cmd using Windows terminal there is no right click options enabled, whereas using the old cmd you get: ![image](https://user-images.githubusercontent.com/3229632/69501798-3f30ec00-0ebd-11ea-97ce-f12331226c54.png) It'd be great if a future version of Windows Terminal baked this in by default across all shells - it's really useful to have

claunia commented

@wleepang commented on GitHub (Dec 29, 2019):

I'm using Version: 0.5.2762.0, and was tripped up by this today. While I agree that a mapping of "copy" => Ctrl+C is understood as the Windows default, it will also cause confusion with Linux based terminal applications. My solution for now is to map:

{"command": "copy", "keys": ["ctrl+insert"]},
{"command": "paste", "keys": ["ctrl+shift+insert"]},

I've seen this mapping used before as an alternative.

That said, I originally wanted to use:

{"command": "copy", "keys": ["win+c"]},
{"command": "paste", "keys": ["win+v"]},

which maps to the muscle memory I've built using MacOS, however the linter in VSCode told me only ctrl|shift|alt are acceptable modifier keys. Is there a way to allow the win key to be a modifier as well for custom key bindings?

@wleepang commented on GitHub (Dec 29, 2019): I'm using Version: 0.5.2762.0, and was tripped up by this today. While I agree that a mapping of "copy" => Ctrl+C is understood as the Windows default, it will also cause confusion with Linux based terminal applications. My solution for now is to map: ```json {"command": "copy", "keys": ["ctrl+insert"]}, {"command": "paste", "keys": ["ctrl+shift+insert"]}, ``` I've seen this mapping used before as an alternative. That said, I originally wanted to use: ```json {"command": "copy", "keys": ["win+c"]}, {"command": "paste", "keys": ["win+v"]}, ``` which maps to the muscle memory I've built using MacOS, however the linter in VSCode told me only `ctrl|shift|alt` are acceptable modifier keys. Is there a way to allow the `win` key to be a modifier as well for custom key bindings?

claunia commented

@gdamore commented on GitHub (Jan 18, 2020):

I feel pretty strongly about this -- I'm a UNIX user (also the author of the popular tcell package for building console interface apps in Golang), and understand the need to separate copy from delivering the control-c to the application. There are challenging trade-offs here.

However, I really liked legacy conhost's solution to this -- if I have text selected, then Ctrl-C is copy just like windows. And Ctrl-V is paste. If I have no selected text, then CTRL-C is passed through to the application. IMO, these should be the default settings. They should be customizable, in case a user wants to change them.

(On macOS its CMD-C and CMD-V, and I've bound those for Windows Terminal, but what really messes me up is that in every other app on Windows its CTRL. )

To be honest what I really wish is that I could change the rest of Windows to use ALT-C and ALT-V (or META-C and META-V) for copy/paste, which would not collide with most other uses but keep the control bindings available for terminal windows. I do understand why that's not practical -- given the fact that each application manages it's own key bindings.

Another possible solution is to offer some extra modifier (e.g. SHIFT-CTRL-) that would send the control sequence to the application running in the window. Even as a UNIX user, I know for a fact that I use CTRL-C and CTRL-V occasionally in the terminal to control my apps, but far less frequently than I use copy-paste. So I'd prefer to require keyboard-twister in the uncommon case, and be able to use copy-paste like I do everywhere else by default.

@gdamore commented on GitHub (Jan 18, 2020): I feel pretty strongly about this -- I'm a UNIX user (also the author of the popular tcell package for building console interface apps in Golang), and understand the need to separate copy from delivering the control-c to the application. There are challenging trade-offs here. However, I really liked legacy conhost's solution to this -- if I have text selected, then Ctrl-C is copy just like windows. And Ctrl-V is paste. If I have no selected text, then CTRL-C is passed through to the application. IMO, these should be the default settings. They should be customizable, in case a user wants to change them. (On macOS its CMD-C and CMD-V, and I've bound those for Windows Terminal, but what really messes me up is that in every *other* app on Windows its CTRL. ) To be honest what I really wish is that I could change the rest of Windows to use ALT-C and ALT-V (or META-C and META-V) for copy/paste, which would not collide with most other uses but keep the control bindings available for terminal windows. I do understand why that's not practical -- given the fact that each application manages it's own key bindings. Another possible solution is to offer some extra modifier (e.g. SHIFT-CTRL-) that would send the control sequence to the application running in the window. Even as a UNIX user, I know for a fact that I use CTRL-C and CTRL-V occasionally in the terminal to control my apps, but far less frequently than I use copy-paste. So I'd prefer to require keyboard-twister in the uncommon case, and be able to use copy-paste like I do everywhere else by default.

claunia commented

@kzu commented on GitHub (Jan 29, 2020):

Totally agree on making this "smart" depending on whether there's a selection at all.

BTW, this is exactly how the integrated terminal in VS Code behaves, which is awesome.

@kzu commented on GitHub (Jan 29, 2020): Totally agree on making this "smart" depending on whether there's a selection at all. BTW, this is *exactly* how the integrated terminal in VS Code behaves, which is awesome.

claunia commented

@DHowett-MSFT commented on GitHub (Jan 29, 2020):

If you bind Ctrl+C, it will be "smart". There is no way to make Ctrl+V smart.

@DHowett-MSFT commented on GitHub (Jan 29, 2020): If you bind <kbd>Ctrl+C</kbd>, it will be "smart". There is no way to make <kbd>Ctrl+V</kbd> smart.

claunia commented

@kzu commented on GitHub (Jan 29, 2020):

If it will be "smart" already, then it's even more puzzling why this isn't already bound by default (again, as it is in VS Code terminal, where I think people seem to be mostly happy with it)

@kzu commented on GitHub (Jan 29, 2020): If it will be "smart" already, then it's even more puzzling why this isn't already bound by default (again, as it is in VS Code terminal, where I think people seem to be mostly happy with it)

claunia commented

@KirillOsenkov commented on GitHub (Jan 29, 2020):

I'm curious if we have any data or telemetry to indicate what percentage of users prefer Ctrl+C and Ctrl+V to copy/paste. My intuition tells me it'll be the majority. Curious how many people turn on QuickEdit mode in cmd.exe.

@KirillOsenkov commented on GitHub (Jan 29, 2020): I'm curious if we have any data or telemetry to indicate what percentage of users prefer Ctrl+C and Ctrl+V to copy/paste. My intuition tells me it'll be the majority. Curious how many people turn on QuickEdit mode in cmd.exe.

claunia commented

@regs01 commented on GitHub (Feb 3, 2020):

The same way as powershell, ctrl+c should copy if anything selected and break if nothing selected. Even cmd have it - Enter to copy if there is any selection and execute if there is no selection. Though Enter never been really convenient.

There is specifically Break button to enforce break of execution in case of emergency, if there is selection.

@regs01 commented on GitHub (Feb 3, 2020): The same way as powershell, ctrl+c should copy if anything selected and break if nothing selected. Even cmd have it - Enter to copy if there is any selection and execute if there is no selection. Though Enter never been really convenient. There is specifically Break button to enforce break of execution in case of emergency, if there is selection.

claunia commented

@eidylon commented on GitHub (Feb 16, 2020):

Please don't do this. Ctrl+C already has meaning inside terminals that long outdates copy/paste.

I would've expected that the shells hosted by Terminal would interpret the keystrokes. So since CTRL+C/CTRL+V were recently added to cmd.exe, I would've expected them to be passed down the shell and work as expected.

If you are using a different shell (PowerShell, Bash, etc), then I would expect they should be passed down to that shell for it to interpret as expected.

I find it odd that Terminal is interpreting these keys instead of the shell currently in use. I would only expect Terminal to try to interpret any keys you have defined in the key-bindings. Otherwise yeah, they should just be interpreted by the shell in use, so as to provide consistency with what people expect in each shell.

@eidylon commented on GitHub (Feb 16, 2020): > > > Please don't do this. Ctrl+C already has meaning inside terminals that long outdates copy/paste. I would've expected that the shells hosted by Terminal would interpret the keystrokes. So since CTRL+C/CTRL+V were recently added to cmd.exe, I would've expected them to be passed down the shell and work as expected. If you are using a different shell (PowerShell, Bash, etc), then I would expect they should be passed down to that shell for it to interpret as expected. I find it odd that Terminal is interpreting these keys instead of the shell currently in use. I would only expect Terminal to try to interpret any keys you have defined in the key-bindings. Otherwise yeah, they should just be interpreted by the shell in use, so as to provide consistency with what people expect in each shell.

claunia commented

@shtirlic commented on GitHub (Mar 5, 2020):

Hi there, while win+c is working great, win+v does not, I disabled win+v shortcut in Explorer registry section since win+v is special paste in Windows now, but terminal does not respond to win+v

    {
      "command": "copy",
      "keys": [ "win+c" ]
    },
    {
      "command": "paste",
      "keys": [ "win+v" ]
    },

So my goal to mimic cmd+c and cmd+v behavior, and it's 99% ready, the only thing left is just win+v handling with windows terminal

@shtirlic commented on GitHub (Mar 5, 2020): Hi there, while `win+c` is working great, `win+v` does not, I disabled `win+v` shortcut in Explorer registry section since` win+v` is special paste in Windows now, but terminal does not respond to` win+v` ```json { "command": "copy", "keys": [ "win+c" ] }, { "command": "paste", "keys": [ "win+v" ] }, ``` So my goal to mimic cmd+c and cmd+v behavior, and it's 99% ready, the only thing left is just `win+v` handling with windows terminal

claunia commented

@DHowett-MSFT commented on GitHub (Mar 5, 2020):

@shtirlic this isn't the right issue for your comment; this issue is for ctrl.

@DHowett-MSFT commented on GitHub (Mar 5, 2020): @shtirlic this isn't the right issue for your comment; this issue is for <kbd>ctrl</kbd>.

claunia commented

@randomascii commented on GitHub (Mar 28, 2020):

I don't understand why Windows Terminal Preview is favoring Xterm/Gnome compatibility over cmd.exe compatibility, especially for Ctrl+V. I think that will add frustration and will slow adoption from Windows users. But, I tried the recommended bindings to make it work. After reading the documentation I found where to put the recommended snippet (in the global section, in a "keybindings" array, but it is also important to notice the existing keybindings array, because if you paste a new one at then it gets overwritten by the empty array at the bottom. Yay .json!

Anyway, paste this in over the empty keybindings array at the bottom:

"keybindings": [
{
"command": "copy",
"keys": [ "ctrl+c" ]
},
{
"command": "paste",
"keys": [ "ctrl+v" ]
}
],

And please consider favoring Windows compatibility, at least for Ctrl+V. Or make it easier to enable instead of requiring editing of error-prone .json files.

@randomascii commented on GitHub (Mar 28, 2020): I don't understand why Windows Terminal Preview is favoring Xterm/Gnome compatibility over cmd.exe compatibility, especially for Ctrl+V. I think that will add frustration and will slow adoption from Windows users. But, I tried the recommended bindings to make it work. After reading the documentation I found where to put the recommended snippet (in the global section, in a "keybindings" array, but it is also important to notice the existing keybindings array, because if you paste a new one at then it gets overwritten by the empty array at the bottom. Yay .json! Anyway, paste this in over the empty keybindings array at the bottom: "keybindings": [ { "command": "copy", "keys": [ "ctrl+c" ] }, { "command": "paste", "keys": [ "ctrl+v" ] } ], And please consider favoring Windows compatibility, at least for Ctrl+V. Or make it easier to enable instead of requiring editing of error-prone .json files.

claunia commented

@ghost commented on GitHub (Apr 22, 2020):

:tada:This issue was addressed in #5217, which has now been successfully released as Windows Terminal Preview v0.11.1121.0.🎉

Handy links:

@ghost commented on GitHub (Apr 22, 2020): :tada:This issue was addressed in #5217, which has now been successfully released as `Windows Terminal Preview v0.11.1121.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.11.1121.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)

claunia commented

@vadimkantorov commented on GitHub (Apr 27, 2020):

Given that "Ctrl+C" is now default copy keybinding on new installations. how will standard "Ctrl+C" for SIGINT work?

Imagine a long-running console program with some text selected and Ctrl+C typed. What will Windows Terminal do? Copy? Interrupt the program? Both? @carlos-zamora

@vadimkantorov commented on GitHub (Apr 27, 2020): Given that "Ctrl+C" is now default copy keybinding on new installations. how will standard "Ctrl+C" for SIGINT work? Imagine a long-running console program with some text selected and Ctrl+C typed. What will Windows Terminal do? Copy? Interrupt the program? Both? @carlos-zamora

claunia commented

@zadjii-msft commented on GitHub (Apr 27, 2020):

If the user is using the new keybindings:
- If text is selected: Ctrl+c will copy the selected text.
- If text is NOT selected: Ctrl+c will send a interrupt, the same way Ctrl+c usually behaves.

If the user doesn't like that behavior, it's pretty trivial to remove the new Ctrl+c binding from their settings.json, and rely on the Ctrl+shift+c binding that's in defaults.json

@zadjii-msft commented on GitHub (Apr 27, 2020): * If the user is using the new keybindings: - If text is selected: <kbd>Ctrl+c</kbd> will copy the selected text. - If text is **NOT** selected: <kbd>Ctrl+c</kbd> will send a interrupt, the same way <kbd>Ctrl+c</kbd> usually behaves. If the user doesn't like that behavior, it's pretty trivial to remove the new <kbd>Ctrl+c</kbd> binding from their `settings.json`, and rely on the <kbd>Ctrl+shift+c</kbd> binding that's in `defaults.json`

claunia commented

@randomascii commented on GitHub (Apr 27, 2020):

Does Enter now copy text by default? I realized when switching from cmd.exe to the new terminal that I use that to copy text a lot. I'm not sure if there is any significant disadvantage to making that the default, and it seems that the new terminal should, where possible, ease the transition from cmd.exe.

@randomascii commented on GitHub (Apr 27, 2020): Does Enter now copy text by default? I realized when switching from cmd.exe to the new terminal that I use that to copy text a lot. I'm not sure if there is any significant disadvantage to making that the default, and it seems that the new terminal should, where possible, ease the transition from cmd.exe.

claunia commented

@zadjii-msft commented on GitHub (Apr 27, 2020):

@randomascii nope, but that is a lot less common of a scenario for our users then Ctrl+C for copy. There's a balance we need to strike between "keeping the old behavior of conhost" and "making space to create a better experience". For those of our users who actually do want copy on enter, adding it isn't terribly difficult:

        { "command": "copy", "keys": ["enter"] },

but I'd bet most people weren't even aware that feature existed in the original conhost 😆

@zadjii-msft commented on GitHub (Apr 27, 2020): @randomascii nope, but that is a lot less common of a scenario for our users then <kbd>Ctrl+C</kbd> for copy. There's a balance we need to strike between "keeping the old behavior of conhost" and "making space to create a better experience". For those of our users who actually do want copy on enter, adding it isn't terribly difficult: ```json { "command": "copy", "keys": ["enter"] }, ``` but I'd bet most people weren't even aware that feature existed in the original conhost 😆

claunia commented

@rbreaves commented on GitHub (May 31, 2020):

To be honest what I really wish is that I could change the rest of Windows to use ALT-C and ALT-V (or META-C and META-V) for copy/paste, which would not collide with most other uses but keep the control bindings available for terminal windows. I do understand why that's not practical -- given the fact that each application manages it's own key bindings.

@gdamore What you’ve suggested is actually the most practical thing in this thread. Checkout my https://github.com/rbreaves/kinto project.

@kzu

@rbreaves commented on GitHub (May 31, 2020): > To be honest what I really wish is that I could change the rest of Windows to use ALT-C and ALT-V (or META-C and META-V) for copy/paste, which would not collide with most other uses but keep the control bindings available for terminal windows. I do understand why that's not practical -- given the fact that each application manages it's own key bindings. @gdamore What you’ve suggested is actually the most practical thing in this thread. Checkout my https://github.com/rbreaves/kinto project. @kzu

claunia commented