Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Pasted text includes CRLF pairs where unneeded #1091

Closed
d-bingham opened this issue Jun 1, 2019 · 38 comments · Fixed by #3449
Closed

Pasted text includes CRLF pairs where unneeded #1091

d-bingham opened this issue Jun 1, 2019 · 38 comments · Fixed by #3449
Assignees
@d-bingham
Labels
Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Terminal-1911

Comments

@d-bingham
Copy link
Contributor

Multiline text pasted from the clipboard includes CRLF pairs in all cases; this is inappropriate for "Unix-space" sessions, such as WSL.

Environment

Windows build number: Microsoft Windows [Version 10.0.18362.145]
Windows Terminal version (if applicable): 71e19cd82528d66a0a7867cbed85990cfc1685f1

Steps to reproduce

Select multiline text in Terminal.
Copy it (via right-click, ostensibly)
Paste it (again via right-click)

Expected behavior

When pasting into a Unix-space session -- such as WSL -- pasted text should have a reasonable set of line-ending characters.

Actual behavior

Line endings are "doubled" on text paste to Unix-space sessions.
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jun 1, 2019
@d-bingham
Copy link
Contributor Author

image

@d-bingham d-bingham mentioned this issue Jun 1, 2019
Closed
5 tasks
@zadjii-msft zadjii-msft added Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. labels Jun 3, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jun 3, 2019
@zadjii-msft zadjii-msft added this to the Terminal v1.0 milestone Jun 3, 2019
@DHowett-MSFT
Copy link
Contributor

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 DHowett-MSFT changed the title Pasted text includes CRLF pairs where unneeded Pasted text includes too many CRLF pairs where unneeded or too few where needed Jun 3, 2019
@DHowett-MSFT DHowett-MSFT mentioned this issue Jun 3, 2019
Closed
@DHowett-MSFT DHowett-MSFT removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Jun 3, 2019
@DHowett-MSFT DHowett-MSFT mentioned this issue Jun 3, 2019
Closed
@conioh
Copy link

conioh commented Jun 3, 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.

@DHowett-MSFT
Copy link
Contributor

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.

@conioh
Copy link

conioh commented Jun 3, 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.

@DHowett-MSFT
Copy link
Contributor

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 😄

@conioh
Copy link

conioh commented Jun 3, 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

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.

@d-bingham
Copy link
Contributor Author

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.

@DHowett-MSFT
Copy link
Contributor

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

@DHowett-MSFT DHowett-MSFT changed the title Pasted text includes too many CRLF pairs where unneeded or too few where needed Pasted text includes CRLF pairs where unneeded Jun 4, 2019
@ivan-section-io
Copy link

For Unix/WSL I believe this should be CRLFs to CRs, and not CRLFs to LFs
re: #1094 (comment)

@DHowett-MSFT DHowett-MSFT mentioned this issue Jun 10, 2019
Closed
@zadjii-msft zadjii-msft mentioned this issue Jun 18, 2019
Closed
@DHowett-MSFT DHowett-MSFT mentioned this issue Jun 24, 2019
Closed
@sandric
Copy link

sandric commented 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
Copy link

sandric commented 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.

@ghost ghost mentioned this issue Jul 17, 2019
Closed
2 tasks
This was referenced Nov 3, 2019
Closed
Closed
@d-bingham d-bingham mentioned this issue Nov 5, 2019
Merged
5 tasks
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Nov 6, 2019
zadjii-msft pushed a commit that referenced this issue Nov 6, 2019
@d-bingham @zadjii-msft
Replacing \r\n line endings with \r line endings (#3449)
fee3fdf 
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request

<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References

#1091 
#1094 
#2390 
#3314

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes #1091
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

Combination of the PRs #1094, #2390, and #3314, especially as discussed in #3314.

In short, this changes line endings from Windows-space \r\n to the more universal \r.

<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

Copied and pasted text into the terminal without the patch, line endings were doubled.
With the patch, line endings weren't doubled.


--------------------

* Replacing \r\n line endings with \r line endings

* Fixing Formatting
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Nov 6, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Nov 6, 2019
@JCMais
Copy link

JCMais commented 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

@DHowett-MSFT DHowett-MSFT mentioned this issue Nov 7, 2019
Closed
@d-bingham d-bingham mentioned this issue Nov 9, 2019
Closed
@erwa
Copy link

erwa commented Nov 10, 2019 •
edited
Loading

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

@zadjii-msft
Copy link
Member

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

@erwa
Copy link

erwa commented Nov 11, 2019

Gotcha, thanks for the ETA, Mike. I eagerly await the next preview release :).

@DHowett-MSFT DHowett-MSFT mentioned this issue Nov 18, 2019
Closed
@zadjii-msft zadjii-msft mentioned this issue Nov 19, 2019
Closed
@j4james j4james mentioned this issue Nov 24, 2019
Closed
@DHowett-MSFT DHowett-MSFT mentioned this issue Nov 25, 2019
Closed
@ghost
Copy link

ghost commented Nov 26, 2019

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

Handy links:

@erwa
Copy link

erwa commented Nov 27, 2019

YESS!! Finally!! I can confirm this issue is fixed in the new preview release. Thank you for fixing this!

@erwa
Copy link

erwa commented Nov 27, 2019

One thing I prefer about using the Windows Terminal over the Ubuntu Shell is Windows Terminal has tabs support built-in whereas the Ubuntu Shell does not (I end up using tmux instead).

@DHowett-MSFT DHowett-MSFT mentioned this issue Dec 2, 2019
Closed
@paul-michalik
Copy link

To be honest I am running into these issues since update to 0.10.781.0.

@DHowett-MSFT
Copy link
Contributor

Commenting on a closed issue is not a very good way to get help. Would you mind putting together a more robust bug report so that we can try to reproduce it?

@paul-michalik
Copy link

paul-michalik commented Mar 25, 2020 •
edited
Loading

@DHowett-MSFT Yep, will do. Although, I am having a hard time to navigate around all the issues which somehow look to be related to copy-pasting from (1) terminal to terminal (2) from an application to terminal. Maybe someone from the team should look over it and aggregate everything into one?

@ThomasLachaux
Copy link

I have the same problem @paul-michalik encounters
When I copy a content that can't fit my window such as an ssh public key on another terminal or even an application like notepad, newlines are inserted where it shouldn't.

I am also an the version 0.10.781.0

@DHowett-MSFT
Copy link
Contributor

You're hitting #5113, which is fixed pending release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@d-bingham d-bingham

Labels
Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Milestone
Terminal-1911