Pasted text includes CRLF pairs where unneeded #1458

@d-bingham commented on GitHub (Jun 1, 2019):

@d-bingham commented on GitHub (Jun 1, 2019): ![image](https://user-images.githubusercontent.com/26487560/58742970-17ba0480-83ef-11e9-908c-b29e3fc1384b.png)

claunia commented

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

This is now the master issue for line feeds on copy/paste. We need a holistic solution that addresses this ("...includes too many line breaks") and #1073 ("... doesn't include line breaks"). 😁

@DHowett-MSFT commented on GitHub (Jun 3, 2019): This is now the master issue for line feeds on copy/paste. We need a holistic solution that addresses this ("...includes too many line breaks") and #1073 ("... doesn't include line breaks"). :grin:

claunia commented

@conioh commented on GitHub (Jun 4, 2019):

@DHowett-MSFT @d-bingham The description talks about WSL, but my issue (#1073) happened with no WSL involvement. It's indeed tricky to reproduce (which I noticed after seeing your comments) but happened without WSL.

@conioh commented on GitHub (Jun 4, 2019): @DHowett-MSFT @d-bingham The description talks about WSL, but my issue (#1073) happened with no WSL involvement. It's indeed tricky to reproduce (which I noticed after seeing your comments) but happened without WSL.

claunia commented

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

Indeed. This is more likely related to the console's output mode and what was written to the screen and how it was written instead of any particular tool.

@DHowett-MSFT commented on GitHub (Jun 4, 2019): Indeed. This is more likely related to the console's output mode and what was written to the screen and how it was written instead of any _particular_ tool.

claunia commented

@conioh commented on GitHub (Jun 4, 2019):

So PR #1094 won't fix it. Either said PR doesn't close this issue or #1073 isn't a duplicate of this issue.

@conioh commented on GitHub (Jun 4, 2019): So PR #1094 won't fix it. Either said PR doesn't close this issue or #1073 isn't a duplicate of this issue.

claunia commented

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

PR #1094 doesn't fix both issues, but we believe that:

We need a holistic solution that addresses this ("...includes too many line breaks") and #1073 ("... doesn't include line breaks").

And this is valuable feedback for 1094 😄

@DHowett-MSFT commented on GitHub (Jun 4, 2019): PR #1094 doesn't fix _both_ issues, but we believe that: > We need a holistic solution that addresses this ("...includes too many line breaks") and #1073 ("... doesn't include line breaks"). And this is valuable feedback for 1094 :smile:

claunia commented

@conioh commented on GitHub (Jun 4, 2019):

Maybe I'm missing something - I admit that I don't know how all this GitHub thing works - but it says above that:

It makes it sound as if once #1094 is approved and merged this issue will be close automatically, and if I understand correctly you agree that it shouldn't.

@conioh commented on GitHub (Jun 4, 2019): Maybe I'm missing something - I admit that I don't know how all this GitHub thing works - but it says above that: ![image](https://user-images.githubusercontent.com/10606081/58841121-21eb3580-8671-11e9-99c1-6fb835233554.png) It makes it sound as if once #1094 is approved and merged this issue will be close automatically, and if I understand correctly you agree that it shouldn't.

claunia commented

@d-bingham commented on GitHub (Jun 4, 2019):

I'm not sure there's really a "holistic" solution here, as @conioh's issue in #1073 is that the text copied to the clipboard doesn't include line breaks, and #1094 fixes a problem with pasted text having CRLFs when LFs are appropriate.

@d-bingham commented on GitHub (Jun 4, 2019): I'm not sure there's really a "holistic" solution here, as @conioh's issue in #1073 is that the text _copied_ to the clipboard doesn't include line breaks, and #1094 fixes a problem with _pasted_ text having CRLFs when LFs are appropriate.

claunia commented

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

Oh, I see: I got my copies and pastes mixed up.
Thanks!

@DHowett-MSFT commented on GitHub (Jun 4, 2019): Oh, I see: I got my copies and pastes mixed up. Thanks!

claunia commented

@ivan-section-io commented on GitHub (Jun 5, 2019):

For Unix/WSL I believe this should be CRLFs to CRs, and not CRLFs to LFs
re: https://github.com/microsoft/terminal/pull/1094#issuecomment-498967181

@ivan-section-io commented on GitHub (Jun 5, 2019): For Unix/WSL I believe this should be CRLFs to CRs, and not CRLFs to LFs re: https://github.com/microsoft/terminal/pull/1094#issuecomment-498967181

claunia commented

@sandric commented on GitHub (Jul 5, 2019):

Sorry to bother, but is there at least any workaround (makes it pretty unusable)? I mean in emacs I can redefine pasting function, is there some piping commands reading clipboard I can run from bash to read clipboard with no doubled newlines?

@sandric commented on GitHub (Jul 5, 2019): Sorry to bother, but is there at least any workaround (makes it pretty unusable)? I mean in emacs I can redefine pasting function, is there some piping commands reading clipboard I can run from bash to read clipboard with no doubled newlines?

claunia commented

@sandric commented on GitHub (Jul 5, 2019):

Ok, I'm not sure if thats the place for it to live, but if anyone struggles with it, here's mine workaround using autohotkey program:

<^t::
  Var := Clipboard
  Clipboard := RegExReplace(Var, "\r\n?|\n\r?", "`n")
  MouseClick, right
return

Now, by pressing LCtrl + t I get normal clipboard output with no doubled newlines, if anyone struggles - workaround for now.

@sandric commented on GitHub (Jul 5, 2019): Ok, I'm not sure if thats the place for it to live, but if anyone struggles with it, here's mine workaround using autohotkey program: ``` <^t:: Var := Clipboard Clipboard := RegExReplace(Var, "\r\n?|\n\r?", "`n") MouseClick, right return ``` Now, by pressing LCtrl + t I get normal clipboard output with no doubled newlines, if anyone struggles - workaround for now.

claunia commented

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

Just wondering if there was any update? I see the latest 0.3 preview didn't address this yet.

@alexjmoore commented on GitHub (Aug 5, 2019): Just wondering if there was any update? I see the latest 0.3 preview didn't address this yet.

claunia commented

@FlipperPA commented on GitHub (Aug 21, 2019):

Plus one on this bug fix. In Sublime Text 3 on Windows, I can copy this following text (which I'm pasting correctly here):

import pyautogui
from time import sleep

for x in range(1, 1000):
    print(x)

I can also paste it to Notepad, PuTTy, or any number of other programs successfully.

When I right-click to paste it into WSL-2 Ubuntu 18.04 emacs, it doubles carriage returns:

The same double-carriage return behavior occurs when pasting to nano or vim. And when I paste it to WSL-2 cmd:

Thanks for all your efforts on bringing these features to Windows. It is looking incredibly promising as the development environment of choice moving forward, but we'll have to polish some chrome with issues like these.

@FlipperPA commented on GitHub (Aug 21, 2019): Plus one on this bug fix. In Sublime Text 3 on Windows, I can copy this following text (which I'm pasting correctly here): ```python import pyautogui from time import sleep for x in range(1, 1000): print(x) ``` I can also paste it to Notepad, PuTTy, or any number of other programs successfully. When I right-click to paste it into WSL-2 Ubuntu 18.04 `emacs`, it doubles carriage returns: ![image](https://user-images.githubusercontent.com/68164/63396073-e0c31180-c393-11e9-9094-00be4be80302.png) The same double-carriage return behavior occurs when pasting to `nano` or `vim`. And when I paste it to WSL-2 `cmd`: ![image](https://user-images.githubusercontent.com/68164/63396123-05b78480-c394-11e9-8e20-3f42434ad743.png) Thanks for all your efforts on bringing these features to Windows. It is looking incredibly promising as the development environment of choice moving forward, but we'll have to polish some chrome with issues like these.

claunia commented

@FlipperPA commented on GitHub (Aug 21, 2019):

Just to follow up, this is occurring both in WSL-1 and WSL-2, as another data point.

@FlipperPA commented on GitHub (Aug 21, 2019): Just to follow up, this is occurring both in WSL-1 and WSL-2, as another data point.

claunia commented

@JCMais commented on GitHub (Sep 7, 2019):

With nano this seems worse, because looks like it starts to replace the current content on the file, right below the pasting point.

@JCMais commented on GitHub (Sep 7, 2019): With nano this seems worse, because looks like it starts to replace the current content on the file, right below the pasting point.

claunia commented

@genio commented on GitHub (Sep 26, 2019):

Please fix this. I cannot explain how frustrating this bug is.

@genio commented on GitHub (Sep 26, 2019): Please fix this. I cannot explain how frustrating this bug is.

claunia commented

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

Appreciate all the hard work on the terminal, I'm using it for my daily work but this one is particularly frustrating. Is there any workaround?

@dquist commented on GitHub (Oct 4, 2019): Appreciate all the hard work on the terminal, I'm using it for my daily work but this one is particularly frustrating. Is there any workaround?

claunia commented

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

I agree this is currently the most frustrating issue with Windows Terminal - WSL

Ok, I'm not sure if thats the place for it to live, but if anyone struggles with it, here's mine workaround using autohotkey program:
<^t::
  Var := Clipboard
  Clipboard := RegExReplace(Var, "\r\n?|\n\r?", "`n")
  MouseClick, right
return
Now, by pressing LCtrl + t I get normal clipboard output with no doubled newlines, if anyone struggles - workaround for now.

Thanks for this, adjusted a bit to be able to use Ctrl + Shift + V while in WindowsTerminal, to not interfere with other apps

#if WinActive("ahk_exe WindowsTerminal.exe")
    ^+v::
        Var := Clipboard
        Clipboard := RegExReplace(Var, "\r\n?|\n\r?", "`n")
        MouseClick, right
        return
#if

@ilirb commented on GitHub (Oct 4, 2019): I agree this is currently the most frustrating issue with Windows Terminal - WSL > Ok, I'm not sure if thats the place for it to live, but if anyone struggles with it, here's mine workaround using autohotkey program: > > ``` > <^t:: > Var := Clipboard > Clipboard := RegExReplace(Var, "\r\n?|\n\r?", "`n") > MouseClick, right > return > ``` > > Now, by pressing LCtrl + t I get normal clipboard output with no doubled newlines, if anyone struggles - workaround for now. Thanks for this, adjusted a bit to be able to use `Ctrl + Shift + V` while in WindowsTerminal, to not interfere with other apps ``` #if WinActive("ahk_exe WindowsTerminal.exe") ^+v:: Var := Clipboard Clipboard := RegExReplace(Var, "\r\n?|\n\r?", "`n") MouseClick, right return #if ```

claunia commented

@CoskunSunali commented on GitHub (Oct 5, 2019):

There is also another problem where we lose new lines. I don't know if the two might be related.

#52

@CoskunSunali commented on GitHub (Oct 5, 2019): There is also another problem where we lose new lines. I don't know if the two might be related. #52

claunia commented

@gitfool commented on GitHub (Oct 5, 2019):

ConEmu gets this right. I'm reluctant to switch to Microsoft Terminal until this is working; functional copy paste from Windows to Linux and vice versa is crucial!

@gitfool commented on GitHub (Oct 5, 2019): ConEmu gets this right. I'm reluctant to switch to Microsoft Terminal until this is working; functional copy paste from Windows to Linux and vice versa is crucial!

claunia commented

@FingerlessGlov3s commented on GitHub (Oct 20, 2019):

I'm getting this issue, now its happening on bash.exe as well as the new terminal on 1909. Only happens for me when I scroll down on nano. using page down.

How's this BUG not been fixed yet?

I was using bash.exe on 1809, and it worked fine. I thought I'd update to 1909, but now my copy n paste is broken for WSL, I'll have to use putty again now.

More detail:
You nano a file in WSL, press page down, select and copy few lines of code. You then press return few times and then paste it in. Most return lines are ignored and line ending are not honoured so you get will window width worth of spaces as well as no return line.

Not sure if its a WSL issue or the new terminal. Looking more towards WSL.

@FingerlessGlov3s commented on GitHub (Oct 20, 2019): I'm getting this issue, now its happening on bash.exe as well as the new terminal on 1909. Only happens for me when I scroll down on nano. using page down. How's this BUG not been fixed yet? I was using bash.exe on 1809, and it worked fine. I thought I'd update to 1909, but now my copy n paste is broken for WSL, I'll have to use putty again now. More detail: You nano a file in WSL, press page down, select and copy few lines of code. You then press return few times and then paste it in. Most return lines are ignored and line ending are not honoured so you get will window width worth of spaces as well as no return line. Not sure if its a WSL issue or the new terminal. Looking more towards WSL.

claunia commented

@dquist commented on GitHub (Oct 21, 2019):

How's this BUG not been fixed yet?

Windows Terminal is still in public preview.

@dquist commented on GitHub (Oct 21, 2019): > How's this BUG not been fixed yet? Windows Terminal is still in public preview.

claunia commented

@FingerlessGlov3s commented on GitHub (Oct 21, 2019):

That it is 😉

Isn't the idea of the preview to get feedback and bugs for the app?

@FingerlessGlov3s commented on GitHub (Oct 21, 2019): That it is 😉 Isn't the idea of the preview to get feedback and bugs for the app?

claunia commented

@tejasvi commented on GitHub (Oct 29, 2019):

As of now, is there any workaround while pasting in vim?

@tejasvi commented on GitHub (Oct 29, 2019): As of now, is there any workaround while pasting in vim?

claunia commented

@FingerlessGlov3s commented on GitHub (Oct 29, 2019):

As of now, is there any workaround while pasting in vim?

You can use Xmobaterm to use wsl and that doesn't have the issue.

@FingerlessGlov3s commented on GitHub (Oct 29, 2019): > As of now, is there any workaround while pasting in vim? You can use Xmobaterm to use wsl and that doesn't have the issue.

claunia commented

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

Thank you everyone!

Glad to see this finally fixed, it was one of the major pain points while using the new Terminal

@JCMais commented on GitHub (Nov 6, 2019): Thank you everyone! Glad to see this finally fixed, it was one of the major pain points while using the new Terminal

claunia commented

@erwa commented on GitHub (Nov 10, 2019):

Is this fix available in any released preview version of Terminal? It doesn't appear to be in v0.6.2951.0.

@erwa commented on GitHub (Nov 10, 2019): Is this fix available in any released preview version of Terminal? It doesn't appear to be in v0.6.2951.0.

claunia commented

@zadjii-msft commented on GitHub (Nov 11, 2019):

@erwa not yet. v0.6.2951.0 was the "1910" Terminal milestone, and this is fixed for the "1911" milestone. It will be in the next released preview version of the Terminal, sometime later in November.

@zadjii-msft commented on GitHub (Nov 11, 2019): @erwa not yet. v0.6.2951.0 was the "1910" Terminal milestone, and this is fixed for the "1911" milestone. It will be in the next released preview version of the Terminal, sometime later in November.

claunia commented