Include Ctrl+C, Ctrl+V keybindings by default

[kzu]

I've read the other "copy not working" bugs and the universal suggestion seems to be "just create your own keybinding".

It's quite puzzling for a Windows terminal to not come with the most commonly used Windows shortcuts ever.

I'd suggest these two are added to the product, and people can instead change (or remove them) if they wish. I guess that's a much more intuitive default.

For others wondering why they are missing, just add these two to your keybindings:

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

Just to add to the discussion: the built-in Terminal in VS Code supports this out of the box too, which is awesome.

[KirillOsenkov]

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.

[ealsur]

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/

[pedroreys]

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.

[bradwilson]

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

[DHowett-MSFT]

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]

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.

[KirillOsenkov]

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

[bradwilson]

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

[sgreenmsft]

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

[impguard]

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

[sgreenmsft]

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

[durack1]

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

[wleepang]

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?

[gdamore]

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.

[kzu]

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.

[DHowett-MSFT]

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

[kzu]

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)

[KirillOsenkov]

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.

[regs01]

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.

[eidylon]

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.

[shtirlic]

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

[DHowett-MSFT]

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

[randomascii]

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.

[ghost]

🎉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
• Store Download

[vadimkantorov]

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

[zadjii-msft]

• 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

[randomascii]

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.

[zadjii-msft]

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

[rbreaves]

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:/rbreaves/kinto project.

@kzu

[stewSquared]

Okay great. Now how do we disable this?

-- sad linux user

Edit: Nevermind. Found it in settings.json and deleted it.

[installwindows]

Coming from Linux, it was confusing to ctrl-v in vim and see my last pasta. Had to google on how to get the standard behavior.

[churchid]

The problem with a terminal application commandeering these shortcuts is that when you run applications inside of the terminal and find yourself with a need to enter that key combination inside the terminal, your SOL. Registered voter against the new default, but I guess the change is in, so will go delete it.

[stewSquared]

the percentage of users expecting Ctrl+V to result in "verbatim insert mode."

The fact people think this keybinding is obscure demonstrates ignorance. I recommend learning to use the standard keybindings before bashing them. (heh)

What ctrl+v does depends on what terminal application is running. For people who use terminals on a daily basis, this usually means "page down" for pagers and editors (reading a man page, emacs, vim). alt-v is usually page up. Counter to your intuition, this is quite frequently used.

At this point, why not steal the keybindings for ctrl-a, ctrl-t, and crtl-w, since windows users expect them to be select all, new tab, and close tab? The fact is, these are also very useful keybindings in terminal applications. We should encourage people to leave their comfort zone and learn the terminal, instead of defaulting to a Frankenstein with inconsistent exceptions.