Copy &amp; Paste Keybindings #1290

@zadjii-msft commented on GitHub (May 23, 2019):

This sounds right up @carlos-zamora's alley

@zadjii-msft commented on GitHub (May 23, 2019): This sounds right up @carlos-zamora's alley

claunia commented

@zadjii-msft commented on GitHub (May 23, 2019):

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

@zadjii-msft commented on GitHub (May 23, 2019): 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).

claunia commented

@DHowett-MSFT commented on GitHub (May 23, 2019):

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

@DHowett-MSFT commented on GitHub (May 23, 2019): I must insist that the default bindings for this not be `Ctrl+`-only.

claunia commented

@DHowett-MSFT commented on GitHub (May 23, 2019):

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

@DHowett-MSFT commented on GitHub (May 23, 2019): Agh, sorry. I didn't intend to close this issue.

claunia commented

@CobusKruger commented on GitHub (May 23, 2019):

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?

@CobusKruger commented on GitHub (May 23, 2019): > 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?

claunia commented

@DHowett-MSFT commented on GitHub (May 23, 2019):

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

@DHowett-MSFT commented on GitHub (May 23, 2019): Maybe we'll need profile-specific key bindings. Right now, all binds are re-bindable :smile:

claunia commented

@namatoj commented on GitHub (May 25, 2019):

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.

@namatoj commented on GitHub (May 25, 2019): 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.

claunia commented

@CobusKruger commented on GitHub (May 25, 2019):

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

@CobusKruger commented on GitHub (May 25, 2019): @namatoj That's perfect; exactly the way it should be.

claunia commented

@driver1998 commented on GitHub (May 30, 2019):

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

@driver1998 commented on GitHub (May 30, 2019): I guess we should at least support Ctrl-Insert/Shift-Insert/Shift-Delete if Ctrl-C/V/X may have conflicts?

claunia commented

@mikepurvis commented on GitHub (Jun 6, 2019):

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.

@mikepurvis commented on GitHub (Jun 6, 2019): 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.

claunia commented

@DHowett-MSFT commented on GitHub (Jun 6, 2019):

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.

@DHowett-MSFT commented on GitHub (Jun 6, 2019): All of the discussion about "<kbd>CTRL+C</kbd> being copy only if something is selected" ignores <kbd>CTRL+V</kbd> -- there's no indicator to know that we _should_ paste, and if one values consistency above all else it's problematic to say "<kbd>CTRL+C</kbd> only works when X, but <kbd>CTRL+V</kbd> works always". The alternative, "<kbd>CTRL+C</kbd> if selected, <kbd>CTRL+SHIFT+V</kbd> to paste always" isn't particularly consistent either.

claunia commented

@mikepurvis commented on GitHub (Jun 7, 2019):

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.

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

claunia commented

@mdtauk commented on GitHub (Jun 7, 2019):

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.

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

claunia commented

@RobCannon commented on GitHub (Jun 8, 2019):

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

@RobCannon commented on GitHub (Jun 8, 2019): @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.

claunia commented

@mdtauk commented on GitHub (Jun 8, 2019):

@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

@mdtauk commented on GitHub (Jun 8, 2019): > @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

claunia commented

@NatoBoram commented on GitHub (Jun 22, 2019):

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.

@NatoBoram commented on GitHub (Jun 22, 2019): [Gnome Terminal](https://help.gnome.org/users/gnome-terminal/stable/txt-copy-paste.html) have a consistent keybinding that's not intuitive at first, but easy to adopt, and not too far from the usual <kbd>CTRL + C</kbd> for copy. <kbd>CTRL + C</kbd> : Cancel <kbd>CTRL + Shift + C</kbd> : Copy <kbd>CTRL + Shift + V</kbd> : 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](https://wiki.archlinux.org/index.php/Copying_text_from_a_terminal) and [MacOS](https://support.apple.com/guide/terminal/trmlshtcts). Really, I don't think we have any excuses since [Command Prompt](https://blogs.msdn.microsoft.com/zainnab/2010/07/21/copy-and-paste-with-the-command-prompt/) uses <kbd>Enter</kbd> for copy and <kbd>Right Click</kbd> for paste.

claunia commented

@RobCannon commented on GitHub (Jun 22, 2019):

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

@RobCannon commented on GitHub (Jun 22, 2019): @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.

claunia commented

@MythreyaK commented on GitHub (Jun 22, 2019):

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.

@MythreyaK commented on GitHub (Jun 22, 2019): Also, since the Conhost also lives here; the effects of pasting text obtained with `Ctrl+C` and `Ctrl+Shift+C` has different effects. ![image](https://user-images.githubusercontent.com/26112391/59968089-4c822d00-9551-11e9-8dcf-b9ef293bf40a.png) 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.

claunia commented

@NatoBoram commented on GitHub (Jun 26, 2019):

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

@NatoBoram commented on GitHub (Jun 26, 2019): > Everywhere else in Windows, <kbd>Ctrl + C</kbd> 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 <kbd>Enter</kbd> for copy and <kbd>Right Click</kbd> for paste.~~ \*Ahem* I mean, it is hard to adjust the behavior for one Operating System. 🧂

claunia commented

@codefoster commented on GitHub (Jul 11, 2019):

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.

@codefoster commented on GitHub (Jul 11, 2019): 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`.

claunia commented

@conan commented on GitHub (Jul 26, 2019):

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.

@conan commented on GitHub (Jul 26, 2019): 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.

claunia commented

@ghost commented on GitHub (Aug 3, 2019):

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

Handy links:

@ghost commented on GitHub (Aug 3, 2019): :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](https://github.com/microsoft/terminal/releases/tag/v0.3.2142.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)

claunia commented

@kennethz3 commented on GitHub (Aug 6, 2019):

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

@kennethz3 commented on GitHub (Aug 6, 2019): > > > 🎉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" ] } ```

claunia commented

@krlinus commented on GitHub (Aug 7, 2019):

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

@krlinus commented on GitHub (Aug 7, 2019): 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

claunia commented

@DHowett-MSFT commented on GitHub (Aug 7, 2019):

nobody thought about

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

@DHowett-MSFT commented on GitHub (Aug 7, 2019): > nobody thought about You mean #524 and #2152 (which is a pull request by one of the team members?)

claunia commented

@MythreyaK commented on GitHub (Aug 7, 2019):

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

@MythreyaK commented on GitHub (Aug 7, 2019): 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!)?

claunia commented

@villevaltonen commented on GitHub (Aug 14, 2019):

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!

@villevaltonen commented on GitHub (Aug 14, 2019): 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!

claunia commented

@0x4ndy commented on GitHub (Sep 29, 2019):

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.

@0x4ndy commented on GitHub (Sep 29, 2019): 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.

claunia commented

@ltomes commented on GitHub (Oct 24, 2019):

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.

@ltomes commented on GitHub (Oct 24, 2019): 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](https://github.com/microsoft/terminal/pull/1093/files#diff-6fd69d4753b07562ec2a5f5622a46c7eR46) 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.

claunia commented

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

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

@DHowett-MSFT commented on GitHub (Oct 24, 2019): @ltomes So, the change that made Terminal choose between SIGINT and <kbd>Ctrl+C</kbd> 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:

claunia commented

@ltomes commented on GitHub (Oct 24, 2019):

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

@ltomes commented on GitHub (Oct 24, 2019): Thanks for the followup/explanation @DHowett-MSFT! I feel more sane now seeing that change, I thought I was to tired to function. 🤣

claunia commented

@jernejk commented on GitHub (Nov 6, 2019):

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

@jernejk commented on GitHub (Nov 6, 2019): Thanks for the keybindings. Now Windows Terminal works like Windows cmd. :) (I was actually surprised that it didn't work like default Windows cmd)

claunia commented

@brunofin commented on GitHub (Nov 13, 2019):

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.

@brunofin commented on GitHub (Nov 13, 2019): > [Gnome Terminal](https://help.gnome.org/users/gnome-terminal/stable/txt-copy-paste.html) 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](https://wiki.archlinux.org/index.php/Copying_text_from_a_terminal) and [MacOS](https://support.apple.com/guide/terminal/trmlshtcts). > > Really, I don't think we have any excuses since [Command Prompt](https://blogs.msdn.microsoft.com/zainnab/2010/07/21/copy-and-paste-with-the-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.

claunia commented

@Deilan commented on GitHub (Nov 19, 2019):

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.

@Deilan commented on GitHub (Nov 19, 2019): 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.

claunia commented

@darthcabs commented on GitHub (Nov 30, 2019):

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

@darthcabs commented on GitHub (Nov 30, 2019): 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

claunia commented

@DHowett-MSFT commented on GitHub (Nov 30, 2019):

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

@DHowett-MSFT commented on GitHub (Nov 30, 2019): @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"] } ] ```

claunia commented

@darthcabs commented on GitHub (Nov 30, 2019):

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

@darthcabs commented on GitHub (Nov 30, 2019): @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!

claunia commented

@krlinus commented on GitHub (Dec 12, 2019):

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

@krlinus commented on GitHub (Dec 12, 2019): > @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.

claunia commented

@bjorn-ali-goransson commented on GitHub (Mar 18, 2020):

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.

@bjorn-ali-goransson commented on GitHub (Mar 18, 2020): 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.

claunia commented

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

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.

@DHowett-MSFT commented on GitHub (Mar 19, 2020): 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.

claunia commented

@bjorn-ali-goransson commented on GitHub (Mar 19, 2020):

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:

@bjorn-ali-goransson commented on GitHub (Mar 19, 2020): 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:

claunia commented

@TomasHubelbauer commented on GitHub (Mar 22, 2020):

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.

@TomasHubelbauer commented on GitHub (Mar 22, 2020): 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.

claunia commented

@kvietmeier commented on GitHub (Mar 26, 2020):

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.

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

claunia commented

@yepthatsjason commented on GitHub (Apr 9, 2020):

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

@yepthatsjason commented on GitHub (Apr 9, 2020): @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.

claunia commented

@mikepurvis commented on GitHub (Apr 9, 2020):

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.

@mikepurvis commented on GitHub (Apr 9, 2020): > 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.

claunia commented

@bjorn-ali-goransson commented on GitHub (Apr 9, 2020):

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:

@bjorn-ali-goransson commented on GitHub (Apr 9, 2020): 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:

claunia commented

@mikepurvis commented on GitHub (Apr 9, 2020):

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.

@mikepurvis commented on GitHub (Apr 9, 2020): 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.

claunia commented

@bjorn-ali-goransson commented on GitHub (Apr 9, 2020):

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:

@bjorn-ali-goransson commented on GitHub (Apr 9, 2020): 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:

claunia commented

@jave27 commented on GitHub (Apr 9, 2020):

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

@jave27 commented on GitHub (Apr 9, 2020): 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. :)

claunia commented

2026-01-30 22:21:26 +00:00

@gakio12 commented on GitHub (Apr 10, 2020):

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.

@gakio12 commented on GitHub (Apr 10, 2020): 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.

claunia commented

@bjorn-ali-goransson commented on GitHub (Apr 10, 2020):

Why not have both Ctrl+C/V and Ctrl+Shift+C/V though?

@bjorn-ali-goransson commented on GitHub (Apr 10, 2020): Why not have both Ctrl+C/V **and** Ctrl+Shift+C/V though?

claunia commented

2026-01-30 22:21:26 +00:00

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

@bjorn-ali-goransson We actually just changed the default settings file to include both, so users can easily opt-out of Ctrl+C/Ctrl+V if they want.

See this PR and #5187

@zadjii-msft commented on GitHub (Apr 10, 2020): @bjorn-ali-goransson We actually just changed the default settings file to include both, so users can easily opt-out of <kbd>Ctrl+C</kbd>/<kbd>Ctrl+V</kbd> if they want. See [this PR](https://github.com/microsoft/terminal/pull/5217/files#diff-c810a386e5041cec5e671e90b425c1c0R60-R61) and #5187

claunia commented

2026-01-30 22:21:26 +00:00

@soilstack commented on GitHub (Apr 19, 2020):

It appears as though the popular behavior has been set as the default.

Nonsense. It means people abandon trying to fix it, or don't know that it can be fixed.

It's the reason I am on this thread at all now.

@soilstack commented on GitHub (Apr 19, 2020): > * It appears as though the popular behavior has been set as the default. Nonsense. It means people abandon trying to fix it, or don't know that it can be fixed. It's the reason I am on this thread at all now.

claunia commented

2026-01-30 22:21:27 +00:00

@DHowett-MSFT commented on GitHub (Apr 19, 2020):

@soilstack thanks. Consider reading the most recent messages on this thread.

@DHowett-MSFT commented on GitHub (Apr 19, 2020): @soilstack thanks. Consider reading the most recent messages on this thread.

claunia commented

2026-01-30 22:21:27 +00:00

@SteveIves commented on GitHub (Jun 9, 2020):

It is truly astounding to me that you guys can't figure out how to make something as fundamental as this work! This is a huge deal. I love everything else about the Terminal app, but this basic flaw catches me out every time I use it.

@SteveIves commented on GitHub (Jun 9, 2020): It is truly astounding to me that you guys can't figure out how to make something as fundamental as this work! This is a huge deal. I love everything else about the Terminal app, but this basic flaw catches me out every time I use it.

claunia commented

2026-01-30 22:21:27 +00:00

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

@SteveIves You know you can change your keybindings to be whatever you'd like, right? If you want Ctrl+C/V as copy-paste, go ahead and add those to your keybindings. If you want Ctrl+Shift+C/V, you can use those too. If you want alt+q as copy and shift+0 as paste, go for it.

As of 1.0, the defaults include Ctrl+Shift+C/V as copy-paste, and new users will also get Ctrl+C/V as copy/paste in their settings file.

EDIT: use whatever subset of these you want:

{
  "keybindings": [
    // Ctrl+C / Ctrl+V for copy paste
    { "keys": "ctrl+c", "command": "copy"},
    { "keys": "ctrl+v", "command": "paste"},

    // Ctrl+Shift+C / Ctrl+Shift+V for copy paste
    { "keys": "ctrl+shift+c", "command": "copy"},
    { "keys": "ctrl+shift+v", "command": "paste"},


    // Disable Ctrl+Shift+C / Ctrl+Shift+V for copy paste
    { "keys": "ctrl+shift+c", "command": "unbound"},
    { "keys": "ctrl+shift+v", "command": "unbound"},
  ]
}

@zadjii-msft commented on GitHub (Jun 9, 2020): @SteveIves You know you can change your keybindings to be whatever you'd like, right? If you want <kbd>Ctrl+C/V</kbd> as copy-paste, go ahead and add those to your keybindings. If you want <kbd>Ctrl+Shift+C/V</kbd>, you can use those too. If you want <kbd>alt+q</kbd> as copy and <kbd>shift+0</kbd> as paste, go for it. As of 1.0, the defaults include <kbd>Ctrl+Shift+C/V</kbd> as copy-paste, and new users will _also_ get <kbd>Ctrl+C/V</kbd> as copy/paste in their settings file. EDIT:  use whatever subset of these you want: ```jsonc { "keybindings": [ // Ctrl+C / Ctrl+V for copy paste { "keys": "ctrl+c", "command": "copy"}, { "keys": "ctrl+v", "command": "paste"}, // Ctrl+Shift+C / Ctrl+Shift+V for copy paste { "keys": "ctrl+shift+c", "command": "copy"}, { "keys": "ctrl+shift+v", "command": "paste"}, // Disable Ctrl+Shift+C / Ctrl+Shift+V for copy paste { "keys": "ctrl+shift+c", "command": "unbound"}, { "keys": "ctrl+shift+v", "command": "unbound"}, ] } ```

claunia commented

@SteveIves commented on GitHub (Jun 10, 2020):

@zadjii-msft yes, I know this, and as a dev I can do this. But if you want Terminal to replace cmd.exe then you need to fix this.

@SteveIves commented on GitHub (Jun 10, 2020): @zadjii-msft yes, I know this, and as a dev I can do this. But if you want Terminal to replace cmd.exe then you need to fix this.

claunia commented

@zadjii-msft commented on GitHub (Jun 10, 2020):

Out of curiosity, what part of

As of 1.0, the defaults include Ctrl+Shift+C/V as copy-paste, and new users will also get Ctrl+C/V as copy/paste in their settings file.

is us not fixing this?

@zadjii-msft commented on GitHub (Jun 10, 2020): Out of curiosity, what part of > As of 1.0, the defaults include <kbd>Ctrl+Shift+C/V</kbd> as copy-paste, and new users will _also_ get <kbd>Ctrl+C/V</kbd> as copy/paste in their settings file. is us not fixing this?

claunia commented

@jagojar commented on GitHub (Jun 11, 2020):

Ctrl+Shift+C/V is not natural. Also not right-click menu? I find Windows Terminal useful, but the lack of the menu and Ctrl+C/V is making me reconsider my options.

@jagojar commented on GitHub (Jun 11, 2020): Ctrl+Shift+C/V is not natural. Also not right-click menu? I find Windows Terminal useful, but the lack of the menu and Ctrl+C/V is making me reconsider my options.

claunia commented