Copy & Paste Keybindings

[CobusKruger]

Environment

Windows build number: 10.0.18362.86
Windows Terminal version (if applicable):

Steps to reproduce

In the standard Windows 10 console, you can enable the use of Ctrl+C/V for copy and paste. Windows Terminal doesn't have this, and it is extremely frustrating.

Expected behavior

Enable the use of Ctrl+C for copy and Ctrl+V for paste.

Actual behavior

Ctrl+C doesn't copy anything, and Ctrl+V just writes ^V at the prompt.

[zadjii-msft]

This sounds right up @carlos-zamora's alley

[zadjii-msft]

Or actually, anyone could hop on this. You'd want to set up copy and paste actions in App.cpp (like _Scroll, for example) that trigger the appropriate actions on the TermControl. There should already be Copy and Paste ShortcutActions, so it's just a matter of registering defaults for them, and wiring the actions to the bindings (see HookupKeyBindings or similar in App.cpp).

[DHowett-MSFT]

I must insist that the default bindings for this not be Ctrl+-only.

[DHowett-MSFT]

Agh, sorry. I didn't intend to close this issue.

[CobusKruger]

I must insist that the default bindings for this not be Ctrl+-only.

I know why you're saying that, and that's of course why the normal console has it behind a setting one must enable. But having them behind Ctrl+Shift or something similar defeats the purpose. It's the muscle memory that make these the keybindings worth having.

For me, having Ctrl+V enter ^V has never been useful and I suspect that this is true for a very significant number of people. Would it be possible to enable this as a setting?

[DHowett-MSFT]

Maybe we'll need profile-specific key bindings. Right now, all binds are re-bindable :smile:

[namatoj]

I like the way that WSL+Bash handles copy/paste. Ctrl+C only copies when something is selected. If nothing is selected then Ctrl+C behaves as usual and sends an SIGINT.

[CobusKruger]

@namatoj That's perfect; exactly the way it should be.

[driver1998]

I guess we should at least support Ctrl-Insert/Shift-Insert/Shift-Delete if Ctrl-C/V/X may have conflicts?

[mikepurvis]

IMO the options should be:

• "Smart" behaviour, where CTRL-C is copy only if something is selected.
• Custom behaviour, with keybindings that default to CTRL-SHIFT-C/V.
• No behaviour, copy is available in the right-click menu on selection.

[DHowett-MSFT]

All of the discussion about "CTRL+C being copy only if something is selected" ignores CTRL+V -- there's no indicator to know that we should paste, and if one values consistency above all else it's problematic to say "CTRL+C only works when X, but CTRL+V works always". The alternative, "CTRL+C if selected, CTRL+SHIFT+V to paste always" isn't particularly consistent either.

[mikepurvis]

But CTRL-C is universally "send a SIGINT", there's a huge ambiguity there. Ubuntu's terminal resolves this by using CTRL-SHIFT-C/V for copy/paste; the MacOS terminal resolves it by using CMD-C for copy and CTRL-C for interrupt.

CTRL-V has no such conflict. Some emacs users might bind it to things, but if you're enough of an emacs power user to be rebinding keys, you're probably using capslock as your meta key anyway.

I think the main risk of making the "smart" behaviour the default is just that users will accidentally interrupt a process because they missed their selection. If that's a concern or we want consistency then I would say to just copy Ubuntu and make the default bindings for both CTRL-SHIFT-C/V.

[mdtauk]

By implementing Customised Keybindings per profile, this could allow the default Ubuntu keyboard shortcuts to behave as they should, or allow the user to change them to allow Windows clipboard shortcuts to behave as they should.

[RobCannon]

@mikepurvis The smart Ctrl-C behavior is used in many Windows terminals with no issues. I like how https://github.com/Eugeny/terminus does it where it flashes a short pop-up to indicate text has been copied or pasted.

[mdtauk]

@mikepurvis The smart Ctrl-C behavior is used in many Windows terminals with no issues. I like how https://github.com/Eugeny/terminus does it where it flashes a short pop-up to indicate text has been copied or pasted.

Tooltips for Copied would be good, especially where Ctrl+C is not always assigned to Copying

[NatoBoram]

Gnome Terminal have a consistent keybinding that's not intuitive at first, but easy to adopt, and not too far from the usual CTRL + C for copy.

CTRL + C : Cancel CTRL + Shift + C : Copy CTRL + Shift + V : Paste

No logic for selection, always works a specific way. I think it's perfect. It would also harmonize with other OSes, since this behaviour is consistent across Linux and MacOS.

Really, I don't think we have any excuses since Command Prompt uses Enter for copy and Right Click for paste.

[RobCannon]

@NatoBoram That is fine as an option. But many people like the smart behavior. Everywhere else in Windows, Ctrl+C is copy and it is hard to adjust the behavior for one app, so I want the smart behavior.

[MythreyaK]

Also, since the Conhost also lives here; the effects of pasting text obtained with Ctrl+C and Ctrl+Shift+C has different effects.

The way the buffer is read is correct for the Ctrl+C a.k.a the smart behavior shortcut (i.e., with the line endings).

All terminal-like apps have this issue (CMD, Powershell, WLS-apps) and since the brains behind all of them lives here, thought I'd post it.

[NatoBoram]

Everywhere else in Windows, Ctrl + C is copy

And in Linux and in MacOS. Windows isn't any different in that regard.

It is hard to adjust the behavior for one app

Yes, which is why Microsoft decided that it would be a great idea to use Enter for copy and Right Click for paste. *Ahem* I mean, it is hard to adjust the behavior for one Operating System. 🧂

[codefoster]

Throwing in another vote (even though the issue is closed) for an option of configuring the smart behavior. I for one would configure smart behavior for copy and CTRL+v for paste always. If I have text highlighted and I want to send a SIGINT I expect to hit ESC and then CTRL+c.

[conan]

Same here, I'd love an option to make ctrl+v paste always, and ctrl+c to copy when selected and SIGINT when no selection exists. This is the behaviour I currently have in conemu.

[ghost]

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

Handy links:

• Release Notes
• Store Download

[kennethz3]

🎉This issue was addressed in #1093, which has now been successfully released as Windows Terminal Preview v0.3.2142.0.🎉

Handy links:

* [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.3.2142.0)

* [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)

Adding these key bindings does the trick

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

[krlinus]

How come nobody thought about doing this the putty way? Currently the entire user base is using putty or cygwin. Select to copy, right click to paste. Nothing easier. Edit: removed bad mannered comment. Sorry

[DHowett-MSFT]

nobody thought about

You mean #524 and #2152 (which is a pull request by one of the team members?)

[MythreyaK]

On a small side note, why does pasting text copied over with Ctrl+C and Ctrl+Shift+C seem to have different effects in powershell (described above in one of the comments, repeated here, 🙈 sorry!)?

[villevaltonen]

Personally I prefer "dumb" copy-behavior i.e. separate binding for it instead of binding ctrl+c (usually SIGINT) to copy, when something is selected and messing with default behavior of many shells. This has potential to become annoying when you accidentally shutdown the application, which is running on foreground, when you're trying to only copy something. The current implementation is great!

[0x4ndy]

I added bindings for Ctrl+C (which copies if selected and sends a SIGINT) and Ctrl+V which work perfectly fine and are very intuitive to me.

[ltomes]

As @aolchawa said, adding

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

to keybindings results in the "Smart" behavior @mikepurvis defined above. I don't fully understand how the terminal chooses between SIGINT and Ctrl+C right now, I don't see a change in #1093, that defines this, I see on line 46 we are now passing trimWhitespace to CopyTextEventArgs. I suppose that must be the part of the change that causes the desired (to me) behavior. There does not appear to be a configuration in profiles.json or the profile schema that can be leveraged to toggle the behavior.

At any rate this is the behavior I was looking for; hopefully my rambling here will save someone a few moments digging through the PR to figure out whats going on.

[DHowett-MSFT]

@ltomes So, the change that made Terminal choose between SIGINT and Ctrl+C was actually #2446. Now, the title is a little misleading: what it really implements is "if a keybinding action says it didn't do anything (or was unhandled), give the Terminal a second shot at handling it". :smile:

[ltomes]

Thanks for the followup/explanation @DHowett-MSFT! I feel more sane now seeing that change, I thought I was to tired to function. 🤣

[jernejk]

Thanks for the keybindings. Now Windows Terminal works like Windows cmd. :) (I was actually surprised that it didn't work like default Windows cmd)

[brunofin]

Gnome Terminal have a consistent keybinding that's not intuitive at first, but easy to adopt, and not too far from the usual CTRL + C for copy.

CTRL + C : Cancel CTRL + Shift + C : Copy CTRL + Shift + V : Paste

No logic for selection, always works a specific way. I think it's perfect. It would also harmonize with other OSes, since this behaviour is consistent across Linux and MacOS.

Really, I don't think we have any excuses since Command Prompt uses Enter for copy and Right Click for paste.

I always override Gnome Terminal to use CTRL+C / CTRL+V instead. Having this one single application using different bindings for copy/paste than the rest of the entire system is infuriating for me.

[Deilan]

Workaround via manual adding keybinding is helpful, but let's call a spade a spade: the issue is not resolved until there are ubiquitous default keybindings for copy-paste feature. Which of course should be able to be overridden. And should be documented for sure.

[darthcabs]

Any particular reason for Ctrl+Insert registering as ;5~ and Shift+Insert registering as ;2~ and therefore not working as keybinding for copy/paste?

I just love these keys and can't understand why that shouldn't work

[DHowett-MSFT]

@darthcabs Would you mind sharing your config file? The only thing that springs to mind is that you may be using chorded binds instead of individual binds:

chorded binds (this will not work, and when it does it will not have the intended effect)

"keybindings": [
    { "command": "copy", "keys": ["ctrl+shift+c", "shift+ins"] }
]

individual binds (this should work; #3324 suggests a problem that we cannot reproduce)

"keybindings": [
    { "command": "copy", "keys": ["ctrl+shift+c"] },
    { "command": "copy", "keys": ["shift+ins"] }
]

[darthcabs]

@DHowett-MSFT I was replying to you when I figured what the problem was... In my laptop's keyboard, the INS key is the same as F12 key.

Before I tried to type INS by pressing FN+F12, but as it turns out, it's easier to map copy/paste in Terminal to ctrl+f12/shift+f12 respectively.

Thanks a lot for the inspiration, lol!

[krlinus]

@darthcabs Would you mind sharing your config file? The only thing that springs to mind is that you may be using chorded binds instead of individual binds:

chorded binds (this will not work, and when it does it will not have the intended effect)

"keybindings": [
  { "command": "copy", "keys": ["ctrl+shift+c", "shift+ins"] }
]

individual binds (this should work; #3324 suggests a problem that we cannot reproduce)

"keybindings": [
  { "command": "copy", "keys": ["ctrl+shift+c"] },
  { "command": "copy", "keys": ["shift+ins"] }
]

For me what worked is shift+insert, not shift+ins - posting here just in case it helps anybody.

[bjorn-ali-goransson]

As we can see, this is a constantly occurring problem because it's unintuitive. See https://github.com/ayugioh2003/today-i-learned/issues/281

Ctrl+C, Ctrl+V should "just work", and there is no way of going around that. The users have made (and keep on doing) their verdict.

And as the new command line tool (not this one) works "correctly", ie. as expected, this one should too. If you developers are fond of another scenario, please add it as a setting and let the popular behavior be the default.

[DHowett-MSFT]

I appreciate your input here. Thanks! Just to underscore a couple of points:

• It is a setting today! These key bindings can be set in profiles.json.
• A preliminary look at the landscape of users who have customized their profiles shows that less than 1% of Terminal users are binding ctrl+c/v. It appears as though the popular behavior has been set as the default.

[bjorn-ali-goransson]

But that's assuming people know how to change it. Pardon my bad manners.

A more meaningful metric would be how many pressed Ctrl+V having something in their clipboard, and then got the ^V, then erased it, or simply ended in quitting the application ...

Den tors 19 mars 2020 02:31Dustin L. Howett (MSFT) notifications@github.com skrev:

[TomasHubelbauer]

For anyone landing on this thread from Google: the default keybindings are Ctrl+Shift+C and Ctrl+Shift+V. I have not found these in my settings, so I wasn't sure what the default are.

Also, I don't see this discussed here, but I think it is worth mentioning: Enter to copy and right-click to paste does not work either.

[kvietmeier]

From an accessibility standpoint having combinations of 3 keys, or a mouse click+key is very difficult if not impossible for people with one hand or otherwise limited hand function. This is a big reason why I can't use emacs and stuck with vi/vim.

The default behavior that we have had in Linux/Xwindows for the last 20yrs is the most accessible. DoubleClick to select a word, tripleclick the line, and right click pastes. This appears to work within a Terminal frame but it doesn't reliably populate the clipboard. Note - ConEmu has this functionality - I can select text in a terminal and it populates the clipboard.

[yepthatsjason]

@DHowett-MSFT, I was also stuck not understanding why copy/paste doesn't work just like every other terminal on Windows or Linux (which is what lead me to this github issue after some searching). I don't think that people prefer this setting, they just have no clue how to change it and don't feel comfortable editing the keybindings file.

[mikepurvis]

doesn't work just like every other terminal on Windows or Linux

That's a little dramatic, given that the present default behaviour of Terminal (Ctrl-Shift-C/V) matches exactly what the default terminal on Ubuntu does.

[bjorn-ali-goransson]

That's a higher-level question; who should we optimize for? Clearly not the windows users ...

Den tors 9 apr. 2020 19:08Mike Purvis notifications@github.com skrev:

[mikepurvis]

I'm just calling out that it's unfair to be clutching our pearls and claiming the Terminal team have made the wrong call here because it's different from "every other terminal on Windows or Linux", when every other terminal on Windows is a third party affair and the team here has copied as defaults what the leading Linux distribution has been doing since forever.

And the only reason this isn't an issue on Mac OS as well is that cmd and ctrl on that system happen to be separate buttons.

[bjorn-ali-goransson]

All fair points Mike, but let's face it, most windows users will not know how to paste in this terminal.

That's my only problem here. Not only mine, but many people, lots of people being quite proficient in windows but no experience at all with linux, and there's a problem with noone knowing just how many. Do we want these people to use terminal or dismiss it as feature-incomplete?

If we're content with the current state of affairs, then at the very least, let's measure how many try pasting but can't.

If we don't want telemetry on this, then how about a small counter and when you've tried it 3 times in 3 minutes, show a notification with a link to this issue.

... I'm kidding, instructions on how to change it.

Den tors 9 apr. 2020 19:57Mike Purvis notifications@github.com skrev:

[jave27]

For telemetry's sake, I just downloaded and built this terminal today, and this is my only major complaint so far. There's an option in Preferences that indicates to me that Ctrl-C/V should work, but it quite obviously doesn't. Please enable the "Smart Ctrl-C" feature mentioned above, it's been my #1 complaint about CMD since the dawn of time. :)

[gakio12]

I want to point out that I found this issue searching for how Windows Terminal implemented copy paste. One of the biggest complaints I hear from developers working on both Linux and Windows is that Windows copy/paste is inconsistent with whatever third party shell is installed and between Linux. Nearly every Linux distribution / terminal uses ctrl+shift+c/v, so I am glad that Windows Terminal also has that set as the default.