[WSL] Newlines when copying from console #55

@adamncasey commented on GitHub (Apr 23, 2020):

It seems the text is copied as a table instead of text with new line characters. Pasting into something like MS Excel and copying back out again to my text editor produces the expected result.

@adamncasey commented on GitHub (Apr 23, 2020): It seems the text is copied as a table instead of text with new line characters. Pasting into something like MS Excel and copying back out again to my text editor produces the expected result.

claunia commented

@jan-glx commented on GitHub (Apr 28, 2020):

For me, copying from Windows terminal - WSL - ssh - tmux to Windows with correct white spaces works (only) by:
select text with the mouse while holding shift and copy with Ctrl+ Insert

@jan-glx commented on GitHub (Apr 28, 2020): For me, copying from Windows terminal - WSL - ssh - tmux to Windows with correct white spaces works (only) by: select text with the mouse while holding <kbd>shift</kbd> and copy with <kbd>Ctrl</kbd>+ <kbd>Insert</kbd>

claunia commented

@fendis0709 commented on GitHub (Nov 2, 2020):

Same issue happens to me.
I can Copy - Paste from WSL Terminal, but when Paste, it doesn't has new line.
It's just inline text. No new line.
Any update on this issue? Is there any work around so I can copy - paste with new line (not inline)?

P.S:
I have enough experience using Linux and currently moving to Windows. I have habit of using Ctrl + Shift + C for Copy and Ctrl + Shift + V for Paste.

@fendis0709 commented on GitHub (Nov 2, 2020): Same issue happens to me. I can Copy - Paste from WSL Terminal, but when Paste, it doesn't has new line. It's just inline text. No new line. Any update on this issue? Is there any work around so I can copy - paste with new line (not inline)? ![image](https://user-images.githubusercontent.com/16249274/97895807-d73e8300-1d66-11eb-9248-6fa1fadcc2c9.png) P.S: I have enough experience using Linux and currently moving to Windows. I have habit of using `Ctrl + Shift + C` for Copy and `Ctrl + Shift + V` for Paste.

claunia commented

@strarsis commented on GitHub (Nov 2, 2020):

@fendis0709: Right, currently one has to just drag and select the text, while not holding the Shift key to avoid this line endings issue.

@strarsis commented on GitHub (Nov 2, 2020): @fendis0709: Right, currently one has to just drag and select the text, while _not_ holding the Shift key to avoid this line endings issue.

claunia commented

@lukeschlather commented on GitHub (Dec 18, 2020):

So, is there an intention to fix this or is using ctrl-shift-c for copy functioning as designed? Because this is annoying.

@lukeschlather commented on GitHub (Dec 18, 2020): So, is there an intention to fix this or is using ctrl-shift-c for copy functioning as designed? Because this is annoying.

claunia commented

@Don-Vito commented on GitHub (Dec 23, 2020):

@lukeschlather - not sure if addresses your needs, but the behavior of copy is configurable (see here: https://docs.microsoft.com/en-us/windows/terminal/customize-settings/actions#copy).
Among the settings, you can decide where the new lines should be preserved or not.

@Don-Vito commented on GitHub (Dec 23, 2020): @lukeschlather - not sure if addresses your needs, but the behavior of copy is configurable (see here: https://docs.microsoft.com/en-us/windows/terminal/customize-settings/actions#copy). Among the settings, you can decide where the new lines should be preserved or not.

claunia commented

@lukeschlather commented on GitHub (Dec 23, 2020):

@Don-Vito where is the settings.json file located? The docs are somewhat vague.

Regardless, stripping newlines when copying seems like a bad default. Is that even a feature people want?

@lukeschlather commented on GitHub (Dec 23, 2020): @Don-Vito where is the settings.json file located? The docs are somewhat vague. Regardless, stripping newlines when copying seems like a bad default. Is that even a feature people want?

claunia commented

@DHowett commented on GitHub (Dec 23, 2020):

by default

if we are doing that by default, it is a bug.

@DHowett commented on GitHub (Dec 23, 2020): > by default if we are doing that by default, it is a bug.

claunia commented

@lukeschlather commented on GitHub (Dec 23, 2020):

Isn't that what this bug is? I just installed WSL2 Ubuntu for the first time and I am seeing this bug. Which has been open for two years and seems like it ought to be a fairly straightforward fix.

@lukeschlather commented on GitHub (Dec 23, 2020): Isn't that what this bug is? I just installed WSL2 Ubuntu for the first time and I am seeing this bug. Which has been open for two years and seems like it ought to be a fairly straightforward fix.

claunia commented

@DHowett commented on GitHub (Dec 23, 2020):

You’d be surprised. There’s a lot of factors here- our shared code with the traditional windows console, its support for line wrapping, it supporting different modes of newline deferral (which directly impact wrapping behavior), and users using prompts that extend to the right column of the screen making us think that the text has wrapped. Nobody on the team hits this with any regularity, and that makes it hard to track down.

@DHowett commented on GitHub (Dec 23, 2020): You’d be surprised. There’s a lot of factors here- our shared code with the traditional windows console, its support for line wrapping, it supporting different modes of newline deferral (which directly impact wrapping behavior), and users using prompts that extend to the right column of the screen making us think that the text has wrapped. Nobody on the team hits this with any regularity, and that makes it hard to track down.

claunia commented

@DHowett commented on GitHub (Dec 23, 2020):

There’s a bug in our tracker that mentions “exact wrap”; this is another likely source of issues here. At its heart, this is a misdetection of an application’s intent to wrap or not.

@DHowett commented on GitHub (Dec 23, 2020): There’s a bug in our tracker that mentions “exact wrap”; this is another likely source of issues here. At its heart, this is a misdetection of an application’s intent to wrap or not.

claunia commented

@lukeschlather commented on GitHub (Dec 24, 2020):

That makes sense. I was reacting to the suggestion that this is a configurable option that was set this way by design. It seems everyone agrees that not copying newlines here is a bug that should be fixed, even if the fix is not obvious.

@lukeschlather commented on GitHub (Dec 24, 2020): That makes sense. I was reacting to the suggestion that this is a configurable option that was set this way by design. It seems everyone agrees that not copying newlines here is a bug that should be fixed, even if the fix is not obvious.

claunia commented

@JeremyCCHsu commented on GitHub (Apr 26, 2021):

I encounter the same when I was working with a remote Ubuntu machine. I found a workaround:
Although direct pasting (ctrl+shift+v or shift+right_click) resulted in a single line, send a signal before pasting somehow works:

tmux

ctrl+B then ctrl+v

VS Code terminal

ctrl+v then ctrl+shift+v

The text I copied is the following

# empty line 
from pathlib import Path
import numpy as np
x = np.zeros([3, 2])

The leading and the trailing empty line(s) are necessary. (The two trailing lines are empty instead of a space, but I have to put a space there for Markdown to display them. Note that when the pasted content is a single-line, it gets white backgrounds.)

Not sure whether the above is useful, but this has become my workaround recently...

@JeremyCCHsu commented on GitHub (Apr 26, 2021): I encounter the same when I was working with a remote Ubuntu machine. I found a workaround: Although direct pasting (ctrl+shift+v or shift+right_click) resulted in a single line, send a **signal** before pasting somehow works: ## tmux `ctrl+B` then `ctrl+v` ![tmux](https://user-images.githubusercontent.com/16027371/116058635-9d658e00-a6b2-11eb-9644-b415188fcc75.png) ## VS Code terminal `ctrl+v` then `ctrl+shift+v` ![vscode](https://user-images.githubusercontent.com/16027371/116058665-a5253280-a6b2-11eb-8142-ec7ae391e831.png) The text I copied is the following ```python # empty line from pathlib import Path import numpy as np x = np.zeros([3, 2]) ``` **The leading and the trailing empty line(s) are necessary.** (The two trailing lines are empty instead of a space, but I have to put a space there for Markdown to display them. Note that when the pasted content is a single-line, it gets white backgrounds.) Not sure whether the above is useful, but this has become my workaround recently...

claunia commented

@wpater commented on GitHub (Apr 27, 2021):

Try to copy text with ctrl c instead of ctrl shift c.

@wpater commented on GitHub (Apr 27, 2021): Try to copy text with `ctrl c` instead of `ctrl shift c`.

claunia commented

@dyipon commented on GitHub (Jul 2, 2021):

Same issues with mcview :/

@dyipon commented on GitHub (Jul 2, 2021): Same issues with mcview :/

claunia commented

@joeycumines commented on GitHub (Jul 27, 2021):

Thanks @wpater, ctrl+c worked....

Why does it work if ctrl+shift+c doesn't, though?

@joeycumines commented on GitHub (Jul 27, 2021): Thanks @wpater, ctrl+c worked.... Why does it work if ctrl+shift+c doesn't, though?

claunia commented

@wpater commented on GitHub (Aug 5, 2021):

@joeycumines

Thanks @wpater, ctrl+c worked....

Why does it work if ctrl+shift+c doesn't, though?

I think that CTRL+SHIFT+C interprets selection as one line. All trailing spaces at the end of visual lines are copied instead of end of line characters.

@wpater commented on GitHub (Aug 5, 2021): @joeycumines > > > Thanks @wpater, ctrl+c worked.... > > Why does it work if ctrl+shift+c doesn't, though? I think that CTRL+SHIFT+C interprets selection as one line. All trailing spaces at the end of visual lines are copied instead of end of line characters.

claunia commented

@rdeforest commented on GitHub (Oct 17, 2021):

Edit to add: problem is back, so while there may still be a problem with The Nut Behind The Wheel, what I wrote below isn't necessarily valid since I still don't know what combination of settings and either pressing or not pressing shift will magicaly do what I want. I'm quoting my original comment below:

This issue is more-or-less resolved for me in that the problem was The Nut Behind The Wheel, aka PEBCAK.

What had confused me was that copying had been working the way I expected for a while then started working the other way. Until I read this issue I didn't know what I had done to change the copy action behavior. In my case I had mis-understood the setting "Text format when copying". It defaults to something other than "Plain text only" and when I had encountered that setting I assumed I would never want rich text of any kind coming from or going to my terminal, so I changed it. After I read this thread I switched the setting to HTML and I got the behavior I expected: multiple lines pasted as multiple lines.

So for me if there is still a bug it is that the purpose and effect of the aforementioned setting doesn't match reality. I still don't understand what it means for the plain text I copy out of a terminal to be formatted as "Both HTML and RTF". In what sense is the content I'm copying "formatted" when I execute the copy action? Shouldn't formatting be happening at a higher/lower protocol layer, depending on which way you think is up? That is, if I were using some (as far as I know non-existent) WebKit-based terminal program and I selected several lines of output from a command, I wouldn't expect the clipboard to contain command output or command output  unless that was literally the output I had copied.

The behavior we're talking about feels to me a lot like the tool (in this case Windows Terminal) is trying too hard to anticipate users' needs instead of just doing The Simplest Thing That Could Possibly Work and letting us figure out how to do the more complex but less frequently needed things with additional tooling and such. I'm more than a little curious what the use case for the single-line-of-text behavior might be. When would I ever want that?

@rdeforest commented on GitHub (Oct 17, 2021): **Edit to add**: problem is back, so while there may still be a problem with The Nut Behind The Wheel, what I wrote below isn't necessarily valid since I still don't know what combination of settings and either pressing or not pressing `shift` will magicaly do what I want. I'm quoting my original comment below: > This issue is more-or-less resolved for me in that the problem was The Nut Behind The Wheel, aka PEBCAK. > > What had confused me was that copying had been working the way I expected for a while then started working the other way. Until I read this issue I didn't know what I had done to change the copy action behavior. In my case I had mis-understood the setting "Text format when copying". It defaults to something other than "Plain text only" and when I had encountered that setting I assumed **I would never want rich text of any kind coming from or going to my terminal**, so I changed it. After I read this thread I switched the setting to HTML and I got the behavior I expected: **multiple lines pasted as multiple lines**. > > So for me if there is still a bug it is that the purpose and effect of the aforementioned setting doesn't match reality. I still don't understand what it means for the plain text I copy out of a terminal to be formatted as "Both HTML and RTF". In what sense is the content I'm copying "formatted" when I execute the copy action? Shouldn't formatting be happening at a higher/lower protocol layer, depending on which way you think is up? That is, if I were using some (as far as I know non-existent) WebKit-based terminal program and I selected several lines of output from a command, I wouldn't expect the clipboard to contain `command output` or `command output ` unless that was literally the output I had copied. > > The behavior we're talking about feels to me a lot like the tool (in this case Windows Terminal) is trying too hard to anticipate users' needs instead of just doing The Simplest Thing That Could Possibly Work and letting us figure out how to do the more complex but less frequently needed things with additional tooling and such. I'm more than a little curious what the use case for the single-line-of-text behavior might be. When would I ever want that?

claunia commented

@seldomworks commented on GitHub (Oct 22, 2021):

Edit to add: problem is back, so while

I agree, the problem is back. Or in my case, I have only noticed it for the first time this week. Something does seem to have broken recently. I see the problem both in windows terminal and windows terminal preview.

@seldomworks commented on GitHub (Oct 22, 2021): > **Edit to add**: problem is back, so while I agree, the problem is back. Or in my case, I have only noticed it for the first time this week. Something does seem to have broken recently. I see the problem both in windows terminal and windows terminal preview.

claunia commented

@rdeforest commented on GitHub (Oct 27, 2021):

I've found some useful things:

if my selection ends after the last non-whitespace on the last line, the selection is copied as a single line
Once I've done that, every selection is single-line until I resize the window

Notably, I'm in X11-selection mode where it automatically copies when I select the text. I don't have to press ctrl-c or ctrl-shift-c. I like it that way.

@rdeforest commented on GitHub (Oct 27, 2021): I've found some useful things: 1. if my selection ends after the last non-whitespace on the last line, the selection is copied as a single line 1. Once I've done that, every selection is single-line until I resize the window Notably, I'm in X11-selection mode where it automatically copies when I select the text. I don't have to press ctrl-c or ctrl-shift-c. I like it that way.

claunia commented