Feature: add copy on select (per Unix terminals) #770

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

@carlos-zamora is working on this currently :)

@zadjii-msft commented on GitHub (May 7, 2019): @carlos-zamora is working on this currently :)

claunia commented

@nizos commented on GitHub (May 7, 2019):

I have no problem doing this. This is how I copy/paste:
Mouse left click and hold to select text.
Release left click.
Mouse right click once on selected text.
It is now in your clipboard.

Microsoft Windows [Version 10.0.18362.86]

@nizos commented on GitHub (May 7, 2019): I have no problem doing this. This is how I copy/paste: Mouse left click and hold to select text. Release left click. Mouse right click once on selected text. It is now in your clipboard. ____________________ Microsoft Windows [Version 10.0.18362.86]

claunia commented

@mikemaccana commented on GitHub (May 8, 2019):

@nizos Selecting should copy the text to the clipboard immediately per any other terminal. Doing additional steps is a workaround, not a fix.

@mikemaccana commented on GitHub (May 8, 2019): @nizos Selecting should copy the text to the clipboard immediately per any other terminal. Doing additional steps is a workaround, not a fix.

claunia commented

@nizos commented on GitHub (May 8, 2019):

@mikemaccana I have read the bug report. I just didn’t know that the terminal is supposed to copy anything selected immediately. Where did you read that it is supposed to work that way? I have always used the method I described to copy text in command prompt.

@nizos commented on GitHub (May 8, 2019): @mikemaccana I have read the bug report. I just didn’t know that the terminal is supposed to copy anything selected immediately. Where did you read that it is supposed to work that way? I have always used the method I described to copy text in command prompt.

claunia commented

@mikemaccana commented on GitHub (May 8, 2019):

@nizos Copying immediately on select has been default on Unix terminals for at least 21 years, but probably longer than that.

@mikemaccana commented on GitHub (May 8, 2019): @nizos Copying immediately on select has been default on Unix terminals for at least 21 years, but probably longer than that.

claunia commented

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

Clearly, lots of people have varying opinions on how they want their text to be copy/pasteable from the terminal. That's why we're hoping to make it a feature that's customizable to however you like :)

@zadjii-msft commented on GitHub (May 8, 2019): Clearly, lots of people have varying opinions on how they want their text to be copy/pasteable from the terminal. That's why we're hoping to make it a feature that's customizable to however you like :)

claunia commented

@carlos-zamora commented on GitHub (May 9, 2019):

Yeah. I'm working on the keybindings. Really just need to make sure I send the VT sequence.

As for the copying immediately on selection, I'll be sure to make a setting and add that functionality.

@carlos-zamora commented on GitHub (May 9, 2019): Yeah. I'm working on the keybindings. Really just need to make sure I send the VT sequence. As for the copying immediately on selection, I'll be sure to make a setting and add that functionality.

claunia commented

@jberanek commented on GitHub (Jun 15, 2019):

Middle mouse button paste would be awesome too.

@jberanek commented on GitHub (Jun 15, 2019): Middle mouse button paste would be awesome too.

claunia commented

@mikemaccana commented on GitHub (Jun 17, 2019):

@jberanek Right click paste works now, but agreed it would be good to allow it to be middle mouse too. You should probably make a separate issue though!

@mikemaccana commented on GitHub (Jun 17, 2019): @jberanek Right click paste works now, but agreed it would be good to allow it to be middle mouse too. You should probably make a separate issue though!

claunia commented

@zadjii-msft commented on GitHub (Jun 18, 2019):

Man what we really need is a way to set mouse-bindings as well as keybindings. I believe @carlos-zamora is working on a spec for that (and I'll let him link the appropriate thread in for that discussion)

@zadjii-msft commented on GitHub (Jun 18, 2019): Man what we _really_ need is a way to set mouse-bindings as well as keybindings. I believe @carlos-zamora is working on a spec for that (and I'll let him link the appropriate thread in for that discussion)

claunia commented

@timriker commented on GitHub (Jun 19, 2019):

More details from #1332 :
Dragging should highlight like console, but automatically put the highlighted text into the clipboard and leave it highlighted.

Selection should NOT include trailing spaces as the current terminal incorrectly does with ctrl-shift-c, It should post multiple lines to the clipboard.
The selection should look for characters are actual spaces, and not blanks and not replace blanks with spaces.

Dragging with alt or control held down should select a block instead of rolling lines.

Clicking the middle mouse button should paste the clipboard.

Mouse wheel should scroll, perhaps 3 lines at a time.

This functionality can be compared with xfce4-terminal or gnome-terminal on a Linux box, or on WSL under X servers like VcXsrv. Also compare to MoboXterm support. XTerm is similar but lacks the block select feature.

@timriker commented on GitHub (Jun 19, 2019): More details from #1332 : Dragging should highlight like console, but automatically put the highlighted text into the clipboard and leave it highlighted. Selection should NOT include trailing spaces as the current terminal incorrectly does with ctrl-shift-c, It should post multiple lines to the clipboard. The selection should look for characters are actual spaces, and not blanks and not replace blanks with spaces. Dragging with alt or control held down should select a block instead of rolling lines. Clicking the middle mouse button should paste the clipboard. Mouse wheel should scroll, perhaps 3 lines at a time. This functionality can be compared with xfce4-terminal or gnome-terminal on a Linux box, or on WSL under X servers like VcXsrv. Also compare to MoboXterm support. XTerm is similar but lacks the block select feature.

claunia commented

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

I am happy that there already seems to be some way to do copy/paste. However, I'm not a big fan of right click performing actions. Typically right click would open a context menu. Trying to open a menu and running a set of commands in a terminal by accident sounds like a nightmare.

I did some voluntary work on Freedesktop.org clipboard specification back in 2007. Clipboards seem to be a rather controversial topic and I think unix clipboards are still not consistent. I tried to post an update to the specification back then to fill in some gaps and add some ideas that I gathered from elsewhere. Not sure what happened after I stopped working on it. However, my original mailing list post seems to still be available if someone is interested. https://lists.freedesktop.org/archives/xdg/2007-November/008985.html

@cyberixae commented on GitHub (Jun 22, 2019): I am happy that there already seems to be some way to do copy/paste. However, I'm not a big fan of right click performing actions. Typically right click would open a context menu. Trying to open a menu and running a set of commands in a terminal by accident sounds like a nightmare. I did some voluntary work on Freedesktop.org clipboard specification back in 2007. Clipboards seem to be a rather controversial topic and I think unix clipboards are still not consistent. I tried to post an update to the specification back then to fill in some gaps and add some ideas that I gathered from elsewhere. Not sure what happened after I stopped working on it. However, my original mailing list post seems to still be available if someone is interested. https://lists.freedesktop.org/archives/xdg/2007-November/008985.html

claunia commented

reference video: https://imgur.com/a/jomxTJY

@Shorotshishir commented on GitHub (Jun 24, 2019):

regarding highlight and copy, I see some abnormal behavior. left click selects a character and if you click and drag from the tab it marks everything in between and copies. if you double click right, it pastes too. Works for any terminal.

@Shorotshishir commented on GitHub (Jun 24, 2019): regarding highlight and copy, I see some abnormal behavior. left click selects a character and if you click and drag from the tab it marks everything in between and copies. if you double click right, it pastes too. Works for any terminal. [reference video: https://imgur.com/a/jomxTJY](https://imgur.com/a/jomxTJY)

claunia commented

2026-01-30 22:03:40 +00:00

@TCB13 commented on GitHub (Jun 24, 2019):

@nizos Copying immediately on select has been default on Unix terminals for at least 21 years, but probably longer than that.

Yeah, basic functionality that should be available from day one in Windows Terminal.

@TCB13 commented on GitHub (Jun 24, 2019): > @nizos Copying immediately on select has been default on Unix terminals for at least 21 years, but probably longer than that. Yeah, basic functionality that should be available from day one in Windows Terminal.

claunia commented

2026-01-30 22:03:40 +00:00

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

It's clear that different users expect different things. Sorry that the preview release default isn't what you're expecting. 😄

@DHowett-MSFT commented on GitHub (Jun 24, 2019): It's clear that different users expect different things. Sorry that the _preview release default_ isn't what you're expecting. :smile:

claunia commented

2026-01-30 22:03:40 +00:00

@carlos-zamora commented on GitHub (Jun 24, 2019):

Pointer bindings: #1553

@carlos-zamora commented on GitHub (Jun 24, 2019): Pointer bindings: #1553

claunia commented

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

Comments from #1496:

Please, please (please!) add a setting to enable PuTTY style text selection behavior in the new terminal.

Randomly left clicking on a terminal should not select 1 character, it should just focus (or keep focus if already focused) the window. Nowhere in windows other than terminal does clicking select a character. This is really annoying in multi-monitor scenarios when you are unsure if a window is focused and you click in and it selects a character...

Selecting text with your mouse should automatically copy to the clipboard onmouseup, there are not many scenarios when selecting text in a terminal does not result in copying to the clipboard so it is weird to have to right-click on press enter to copy.

Selected text should automatically be deselected when the clipboard changes, quite helpful to visually see that the selected text is no longer in the clipboard. Surprisingly useful.

Right click should always be paste (not copy!), regardless of if text is currently selected or not. Very annoying, especially with the first issue, if you select a window which was already focused a character is selected, then right clicking to paste ends up copying the selected character.. grr!

Selection should not be lost when typing in the terminal, if you select some text then type a command, it is helpful for the selection to remain selected. This way you know what is in the clipboard (if the 3rd suggestion is implemented).

Please, please, please implement these, thanks! :)

There's a lot of overlap with #524 here. I personally agree with all of it except point 4 (I prefer middle click paste). From discussion on #524 is looks like they're headed towards configurable mouse button mappings, so rather than a single "putty-style" option I would suggest that:

I agree unconditionally; this seems likely just a bug.

Copy-on-select should be an option

I agree; this makes sense when tied to the same copy-on-select option IMO -- if the selection represents the clipboard, then it makes sense to clear it if the clipboard changes

Personally I prefer middle-click paste, right-click context menu. I think that's a mouse button mapping option.

I agree, unconditionally. I suspect the current behaviour stems from legacy conhost which clears the selection when you start typing, but it makes a bit more sense there, because in conhost selecting also suspends new output.

So I'd propose that rather than "putty-style" we have two options: a mouse-binding for what happens when you middle/right-click, and a "copy-on-select" option that enables 2, 3, and maybe 5 above. This is also close to the way these options are broken out in mintty.

@DHowett-MSFT commented on GitHub (Jun 24, 2019): Comments from #1496: > Please, please (please!) add a setting to enable PuTTY style text selection behavior in the new terminal. > > 1. Randomly left clicking on a terminal should not select 1 character, it should just focus (or keep focus if already focused) the window. Nowhere in windows other than terminal does clicking select a character. This is really annoying in multi-monitor scenarios when you are unsure if a window is focused and you click in and it selects a character... > 2. Selecting text with your mouse should automatically copy to the clipboard onmouseup, there are not many scenarios when selecting text in a terminal does not result in copying to the clipboard so it is weird to have to right-click on press enter to copy. > 3. Selected text should automatically be deselected when the clipboard changes, quite helpful to visually see that the selected text is no longer in the clipboard. Surprisingly useful. > 4. Right click should always be paste (not copy!), regardless of if text is currently selected or not. Very annoying, especially with the first issue, if you select a window which was already focused a character is selected, then right clicking to paste ends up copying the selected character.. grr! > 5. Selection should not be lost when typing in the terminal, if you select some text then type a command, it is helpful for the selection to remain selected. This way you know what is in the clipboard (if the 3rd suggestion is implemented). > > Please, please, please implement these, thanks! :) --- > There's a lot of overlap with #524 here. I personally agree with all of it except point 4 (I prefer middle click paste). From discussion on #524 is looks like they're headed towards configurable mouse button mappings, so rather than a single "putty-style" option I would suggest that: > > 1. I agree unconditionally; this seems likely just a bug. > 2. Copy-on-select should be an option > 3. I agree; this makes sense when tied to the same copy-on-select option IMO -- if the selection represents the clipboard, then it makes sense to clear it if the clipboard changes > 4. Personally I prefer middle-click paste, right-click context menu. I think that's a mouse button mapping option. > 5. I agree, unconditionally. I suspect the current behaviour stems from legacy conhost which clears the selection when you start typing, but it makes a bit more sense there, because in conhost selecting also suspends new output. > > So I'd propose that rather than "putty-style" we have two options: a mouse-binding for what happens when you middle/right-click, and a "copy-on-select" option that enables 2, 3, and maybe 5 above. This is also close to the way these options are broken out in mintty.

claunia commented

@TCB13 commented on GitHub (Jun 25, 2019):

It's clear that different users expect different things. Sorry that the preview release default isn't what you're expecting. 😄

It's not about "different users expect different things", it's about default, proven to work behavior that has been around for 20 years as stated before. I get why the pointer bindings suggested by @carlos-zamora might be a fix for this, however that kind of feature will take a long time to implement because of it's large scope.

Implementing the default copy-on-selection will be much faster and make this terminal work in a predictable manner.

@TCB13 commented on GitHub (Jun 25, 2019): > It's clear that different users expect different things. Sorry that the _preview release default_ isn't what you're expecting. 😄 It's not about "different users expect different things", it's about default, proven to work behavior that has been around for 20 years as stated before. I get why the pointer bindings suggested by @carlos-zamora might be a fix for this, however that kind of feature will take a long time to implement because of it's large scope. Implementing the default copy-on-selection will be much faster and make this terminal work in a predictable manner.

claunia commented

@xmm1989218 commented on GitHub (Jun 25, 2019):

I'm a xshell user, can support right click to popout menu then click copy/paste? I don't like use left select copy, right click paste, for me it always operate incorrectly

@xmm1989218 commented on GitHub (Jun 25, 2019): I'm a xshell user, can support right click to popout menu then click copy/paste? I don't like use left select copy, right click paste, for me it always operate incorrectly

claunia commented

@carlos-zamora commented on GitHub (Jun 25, 2019):

Ok. A lot to unpack on this thread. Let me know if I'm missing anything and I'll try and direct traffic appropriately. There's different ways we all expect to copy a selection on a terminal:

This Issue: copy immediately upon making the selection
- This should be decently easy to implement. We need a setting to enable/disable this. Probably worth making this a global setting, and NOT per profile.
- Added "Help-Wanted" tag for anybody to try and implement. The team and I can provide support.
Mixed Implementation: classic windows copy/paste
- If a selection is active, perform <action> to copy the selection to your clipboard.
  - right click: already implemented
  - middle click: Issue #1612
  - ENTER button: Issue #715 (this also includes moving the selection with the keyboard)
The actions from 2 need to be configurable such that people can enable/disable them as they please. To make these actions configurable, we need Pointer Bindings #1553

@carlos-zamora commented on GitHub (Jun 25, 2019): Ok. A lot to unpack on this thread. Let me know if I'm missing anything and I'll try and direct traffic appropriately. There's different ways we all expect to copy a selection on a terminal: 1. **This Issue**: copy immediately upon making the selection - This should be decently easy to implement. We need a setting to enable/disable this. Probably worth making this a global setting, and NOT per profile. - Added "Help-Wanted" tag for anybody to try and implement. The team and I can provide support. 2. **Mixed Implementation**: classic windows copy/paste - If a selection is active, perform _\<action\>_ to copy the selection to your clipboard. - right click: already implemented - middle click: Issue #1612 - ENTER button: Issue #715 (this also includes moving the selection with the keyboard) 3. The actions from 2 need to be configurable such that people can enable/disable them as they please. To make these actions configurable, we need Pointer Bindings #1553

claunia commented

@pa-jberanek commented on GitHub (Jun 25, 2019):

There are other things a typical Unix/Linux-like terminal allows:

Double left-click to select word, triple-click to select the line
(Option of) right-click to mean extend selection

By the way, I think (most of) this behaviour goes back to around at least 1990, so a bit longer than 20 years...

@pa-jberanek commented on GitHub (Jun 25, 2019): There are other things a typical Unix/Linux-like terminal allows: - Double left-click to select word, triple-click to select the line - (Option of) right-click to mean **extend** selection By the way, I think (most of) this behaviour goes back to around at least 1990, so a bit longer than 20 years...

claunia commented

@mikemaccana commented on GitHub (Jun 25, 2019):

As the submitter I just wanted to update based on the current Preview in the store:

Selecting, pasting into terminal WORKS ✔
Selecting, pasting into terminal, then pasting into another app WORKS ✔
Selecting, then pasting into another app (without pasting into Windows Terminal first) FAILS ❌

@mikemaccana commented on GitHub (Jun 25, 2019): As the submitter I just wanted to **update based on the current Preview in the store**: - Selecting, pasting into terminal WORKS ✔ - Selecting, pasting into terminal, then pasting into another app WORKS ✔ - Selecting, then pasting into another app (without pasting into Windows Terminal first) FAILS ❌

claunia commented

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

Interesting. This is what I'm seeing with 0.2.1715.0

@DHowett-MSFT commented on GitHub (Jun 25, 2019): Interesting. This is what I'm seeing with 0.2.1715.0 ![image](https://user-images.githubusercontent.com/14316954/60124606-d5aa8700-973e-11e9-9dde-b6e9dfc47ca3.png)

claunia commented

@mikemaccana commented on GitHub (Jun 25, 2019):

@DHowett-MSFT Also on 0.2.1715.0. Double checking, you're selecting in the terminal, then pasting into Notepad with Ctrl V? And that you haven't pasted the data anywhere else?

@mikemaccana commented on GitHub (Jun 25, 2019): @DHowett-MSFT Also on 0.2.1715.0. Double checking, you're selecting in the terminal, then pasting into Notepad with `Ctrl V`? And that you haven't pasted the data anywhere else? ![image](https://user-images.githubusercontent.com/172594/60125195-3491ef80-9783-11e9-8f05-d5e944337538.png)

claunia commented

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

I'm selecting in the terminal and right-clicking, which is the current copy binding. If it automatically copied on selection, we wouldn't need issue #524 😄

@DHowett-MSFT commented on GitHub (Jun 25, 2019): I'm selecting in the terminal and right-clicking, which is the current copy binding. If it automatically copied on selection, we wouldn't _need_ issue #524 :smile:

claunia commented

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

(then pasting into Notepad, and nowhere else, with Ctrl+V)

@DHowett-MSFT commented on GitHub (Jun 25, 2019): (then pasting into Notepad, and nowhere else, with <kbd>Ctrl+V</kbd>)

claunia commented

@mikemaccana commented on GitHub (Jun 25, 2019):

OK that's irrelevant. I'm testing whether this bug has been fixed not whether selecting with the existing right click requirement works. 😛

@mikemaccana commented on GitHub (Jun 25, 2019): OK that's irrelevant. I'm testing **whether this bug has been fixed** not whether selecting with the existing right click requirement works. 😛

claunia commented

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

If the ~~bug~~ feature request (note: not a bug, really not a bug, actually a feature request) had been implemented, we would have closed this workitem to much fanfare, and all of its followers would have been notified that they could now (edited: i said not, and it was a typo) select text to copy it.

What compelled you to test it and report that it still didn't work? In an ongoing discussion about how it doesn't work? 😁

@DHowett-MSFT commented on GitHub (Jun 25, 2019): If the ~bug~ feature request (note: not a bug, really not a bug, actually a feature request) had been implemented, we would have closed this workitem to much fanfare, and all of its followers would have been notified that they could now (edited: i said `not`, and it was a typo) select text to copy it. What compelled you to test it and report that it still didn't work? In an ongoing discussion about how it doesn't work? 😁

claunia commented

@mikemaccana commented on GitHub (Jun 25, 2019):

@DHowett-MSFT

What compelled you to test it and report that it still didn't work?

That's not what I reported. Some work has been done on implementing it already:

Selecting, pasting into terminal PARTIALLY WORKS 😐 (two right clicks are needed, one deselects the text, the next one pastes)

Selecting, pasting into terminal, then pasting into another app WORKS ✔

Selecting, then pasting into another app (without pasting into Windows Terminal first) FAILS ❌

(Discussion about whether a feature of all popular terminals for a few decades is a feature or a requirement is a black hole best avoided)

@mikemaccana commented on GitHub (Jun 25, 2019): @DHowett-MSFT > What compelled you to test it and report that it still didn't work? That's not what I reported. Some work has been done on implementing it already: > * Selecting, pasting into terminal PARTIALLY WORKS 😐 (two right clicks are needed, one deselects the text, the next one pastes) > * Selecting, pasting into terminal, then pasting into another app WORKS ✔ > * Selecting, then pasting into another app (without pasting into Windows Terminal first) FAILS ❌ (Discussion about whether a feature of all popular terminals for a few decades is a feature or a requirement is a black hole best avoided)

claunia commented

@ibuioli commented on GitHub (Jun 25, 2019):

The option with copy and paste with right click is nice and is used on too many Terminals right now, but most people wait see a dropdown menu with options like copy/paste/split panels/new tab/etc (most Linux Terminals behave that way).

I prefer this way, but I understand the comfort that represents the current method. If this Terminal is intended to be a more interesting option (which I think is the goal) it has to be completely customizable. Maybe a good option is to give the possibility to choose between a dropdown menu or the selection with the right button, from 'Settings'.
And a much more attractive option is to grant the power to configure the behavior of each button (left, right, center), which would avoid conflicts of the type "I do not like this feature".

@ibuioli commented on GitHub (Jun 25, 2019): The option with copy and paste with right click is nice and is used on too many Terminals right now, but most people wait see a dropdown menu with options like copy/paste/split panels/new tab/etc (most Linux Terminals behave that way). ![terminal_rightclick](https://user-images.githubusercontent.com/7343538/60137570-b3842980-977d-11e9-9edf-2642f0128480.png) I prefer this way, but I understand the comfort that represents the current method. If this Terminal is intended to be a more interesting option (which I think is the goal) it has to be completely customizable. Maybe a good option is to give the possibility to choose between a dropdown menu or the selection with the right button, from 'Settings'. And a much more attractive option is to grant the power to configure the behavior of each button (left, right, center), which would avoid conflicts of the type "I do not like this feature".

claunia commented

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

I don't know if anyone else has mentioned this, but I found out that the copied content will be available only when the thread of the Windows Terminal where you copied the content from is running.

If you try the following steps, you will not get what you copied.

Copy some texts from Windows Terminal, (Highlight text with mouse left button, and right click on the Windows Terminal window).
Close the Windows Terminal app.
You will find out what you copied is gone after you close the application.

@zhwghl commented on GitHub (Jun 26, 2019): I don't know if anyone else has mentioned this, but I found out that the copied content will be available only when the thread of the Windows Terminal where you copied the content from is running. If you try the following steps, you will not get what you copied. 1. Copy some texts from Windows Terminal, (Highlight text with mouse left button, and right click on the Windows Terminal window). 2. Close the Windows Terminal app. 3. You will find out what you copied is gone after you close the application.

claunia commented

@shamoons commented on GitHub (Jun 28, 2019):

Can't wait for this feature to work. Having to use a mouse is detestable

@shamoons commented on GitHub (Jun 28, 2019): Can't wait for this feature to work. Having to use a mouse is detestable

claunia commented

@solacens commented on GitHub (Jul 8, 2019):

Is this my problem or double-clicking words won't smart select the word at the moment?

@solacens commented on GitHub (Jul 8, 2019): Is this my problem or double-clicking words won't smart select the word at the moment?

claunia commented

@carlos-zamora commented on GitHub (Jul 8, 2019):

Is this my problem or double-clicking words won't smart select the word at the moment?

In PR #1197

@carlos-zamora commented on GitHub (Jul 8, 2019): > Is this my problem or double-clicking words won't smart select the word at the moment? In PR #1197

claunia commented

@solacens commented on GitHub (Jul 8, 2019):

Thanks @carlos-zamora

Will it be included in the next preview version from Microsoft Store? Can't wait to test it!

@solacens commented on GitHub (Jul 8, 2019): Thanks @carlos-zamora Will it be included in the next preview version from Microsoft Store? Can't wait to test it!

claunia commented

@shamoons commented on GitHub (Jul 8, 2019):

Do we know when the next preview will be released from the Store?

@shamoons commented on GitHub (Jul 8, 2019): Do we know when the next preview will be released from the Store?

claunia commented

@MoshiBin commented on GitHub (Jul 25, 2019):

Can we have a keybind for paste? I personally like Shift+Insert but if there's a way to set any binding to paste that would be better.

@MoshiBin commented on GitHub (Jul 25, 2019): Can we have a keybind for paste? I personally like `Shift+Insert` but if there's a way to set any binding to paste that would be better.

claunia commented

@cactysman commented on GitHub (Aug 5, 2019):

This currently is the only thing keeping me away from the terminal.

@cactysman commented on GitHub (Aug 5, 2019): This currently is the only thing keeping me away from the terminal.

claunia commented

@mikemaccana commented on GitHub (Aug 5, 2019):

I just tried 0.3, in case there was any updates not mentioned in the thread, status is same as https://github.com/microsoft/terminal/issues/524#issuecomment-505579445

@mikemaccana commented on GitHub (Aug 5, 2019): I just tried 0.3, in case there was any updates not mentioned in the thread, status is same as https://github.com/microsoft/terminal/issues/524#issuecomment-505579445

claunia commented

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

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

Handy links:

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

claunia commented

@DHowett-MSFT commented on GitHub (Sep 19, 2019):

@JonDavis-AZED Sorry, the resolution to the already-resolved “add an optional copy on select feature” request should include something about dragging the tab strip?

@DHowett-MSFT commented on GitHub (Sep 19, 2019): @JonDavis-AZED Sorry, the resolution to the already-resolved “add an optional copy on select feature” request should include something about dragging the tab strip?

claunia commented