starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Make sure WT can copy wrapped lines as a single line #4712

New Issue
Closed
opened 2026-01-30 23:54:42 +00:00 by claunia · 19 comments
claunia commented 2026-01-30 23:54:42 +00:00
Owner
Copy Link

Originally created by @angelog0 on GitHub (Oct 29, 2019).

I created this profile (since WT 0.5),

{
            "guid": "{9c173dff-f524-43df-b40e-29953998c744}",
            "name": "MSYS2 Terminal",
            "commandline": "cmd.exe /c \"set MSYSTEM=MSYS&& set MSYS=winsymlinks:nativestrict&& C:/msys64/usr/bin/bash.exe --login\"",
            "hidden": false,
            "startingDirectory": "C:/msys64/home/user",
            "closeOnExit": true,
            "colorScheme": "MSYS2-Theme",
            "cursorColor": "#FD9D4F",
            "cursorShape": "filledBox",
            "fontFace": "Cascadia Code",
            "fontSize": 11,
            "historySize": 9001,
            "icon": "C:/msys64/msys2.ico",
            "padding": "8, 8, 8, 8",
            "snapOnInput": true// ,
            // "useAcrylic": true,
            // "acrylicOpacity": 0.75
        }

and noticed that when I paste a long line as in
long_line it works wrong

$ ls -lrt /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gc
ls: impossibile accedere a '/usr/lib/gc': No such file or directory
[...]
$ c/ /usr/lib/gcc/ /usr/lib/gcc/

This does not occur in Ubuntu or DOS or PoweShell profiles.

In short, it does not like the end of line when using MSYS2 profile. Maybe you have some suggestions...

(BTW, I copied that line dragging the mouse and pasting with right click, as usually one have to do in WT)

The system is W10 Pro 64 10.0.18362.449.

Originally created by @angelog0 on GitHub (Oct 29, 2019). I created this profile (since WT 0.5), ``` { "guid": "{9c173dff-f524-43df-b40e-29953998c744}", "name": "MSYS2 Terminal", "commandline": "cmd.exe /c \"set MSYSTEM=MSYS&& set MSYS=winsymlinks:nativestrict&& C:/msys64/usr/bin/bash.exe --login\"", "hidden": false, "startingDirectory": "C:/msys64/home/user", "closeOnExit": true, "colorScheme": "MSYS2-Theme", "cursorColor": "#FD9D4F", "cursorShape": "filledBox", "fontFace": "Cascadia Code", "fontSize": 11, "historySize": 9001, "icon": "C:/msys64/msys2.ico", "padding": "8, 8, 8, 8", "snapOnInput": true// , // "useAcrylic": true, // "acrylicOpacity": 0.75 } ``` and noticed that when I paste a long line as in ![long_line](https://user-images.githubusercontent.com/35931460/67782140-b616c880-fa68-11e9-8c72-c4e07a440390.png) it works wrong ``` $ ls -lrt /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gcc/ /usr/lib/gc ls: impossibile accedere a '/usr/lib/gc': No such file or directory [...] $ c/ /usr/lib/gcc/ /usr/lib/gcc/ ``` This does not occur in Ubuntu or DOS or PoweShell profiles. In short, it does not like the end of line when using MSYS2 profile. Maybe you have some suggestions... (BTW, I copied that line dragging the mouse and pasting with right click, as usually one have to do in WT) The system is W10 Pro 64 10.0.18362.449.
claunia commented 2026-01-30 23:54:44 +00:00
Author
Owner
Copy Link

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

This is due to a lack of wrapping copy, not paste.

@DHowett-MSFT commented on GitHub (Oct 29, 2019): This is due to a lack of wrapping copy, not paste.
claunia commented 2026-01-30 23:54:44 +00:00
Author
Owner
Copy Link

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

Broadly, this is related to #780 and #2089.

@DHowett-MSFT commented on GitHub (Oct 29, 2019): Broadly, this is related to #780 and #2089.
claunia commented 2026-01-30 23:54:44 +00:00
Author
Owner
Copy Link

@Biswa96 commented on GitHub (Oct 30, 2019):

Does this happen in latest cygwin also?

@Biswa96 commented on GitHub (Oct 30, 2019): Does this happen in latest cygwin also?
claunia commented 2026-01-30 23:54:45 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Oct 30, 2019):

@Biswa96, I do not use cygwin since 2014. The basic DLL in MSYS2 is the same version:

$ pacman -Ss msys2 | grep runtime
msys/msys2-runtime 3.0.7-6 (base) [installato]
msys/msys2-runtime-devel 3.0.7-6 (msys2-devel) [installato]

BTW, in MinTTY-MSYS2 it works as expected, without problems (the same as in Ubuntu-WT or CMD-WT profiles).

See the MSYS2 profile I posted above, may be it need some adjustment? Some other environment variable or what else?

@angelog0 commented on GitHub (Oct 30, 2019): @Biswa96, I do not use cygwin since 2014. The basic DLL in MSYS2 is the same version: ``` $ pacman -Ss msys2 | grep runtime msys/msys2-runtime 3.0.7-6 (base) [installato] msys/msys2-runtime-devel 3.0.7-6 (msys2-devel) [installato] ``` BTW, in MinTTY-MSYS2 it works as expected, without problems (the same as in Ubuntu-WT or CMD-WT profiles). See the MSYS2 profile I posted above, may be it need some adjustment? Some other environment variable or what else?
claunia commented 2026-01-30 23:54:45 +00:00
Author
Owner
Copy Link

@Biswa96 commented on GitHub (Oct 30, 2019):

Try this "commandline": "C:\\msys64\\usr\\bin\\bash.exe -i -l".

@Biswa96 commented on GitHub (Oct 30, 2019): Try this `"commandline": "C:\\msys64\\usr\\bin\\bash.exe -i -l"`.
claunia commented 2026-01-30 23:54:45 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Oct 30, 2019):

No, it has the same issue. Beside this, I need to set those environment variables.. How with the command line you suggest?

@angelog0 commented on GitHub (Oct 30, 2019): No, it has the same issue. Beside this, I need to set those environment variables.. How with the command line you suggest?
claunia commented 2026-01-30 23:54:45 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Oct 30, 2019):

BTW, the default profile (defaults.json) sets

"initialCols": 120,

but in MSYS2 profile they, really, are 119. See
cl-width-MSYS2 while in Ubuntu profile, effectively, they are 120. See
cl-width-Ubuntu

I typed 34567890 and copy/pasted 1234567890 up to the second line. notice the bigger gap for MSYS2...

@angelog0 commented on GitHub (Oct 30, 2019): BTW, the default profile (`defaults.json`) sets `"initialCols": 120,` but in MSYS2 profile they, really, are 119. See ![cl-width-MSYS2](https://user-images.githubusercontent.com/35931460/67883687-cef4ac00-fb44-11e9-885b-b173293c369c.png) while in Ubuntu profile, effectively, they are 120. See ![cl-width-Ubuntu](https://user-images.githubusercontent.com/35931460/67883786-f8153c80-fb44-11e9-8009-70ba8fbef47b.png) I typed `34567890` and copy/pasted `1234567890` up to the second line. notice the bigger gap for MSYS2...
claunia commented 2026-01-30 23:54:45 +00:00
Author
Owner
Copy Link

@fanvinga commented on GitHub (Nov 4, 2019):

This problem also exists for me. For me, the scenario that caused the issue was that I tried to copy the Dockerfile cross-line command to the Windows Terminal (WSL2), there would be extra blank lines, and bash would be recognized as a one-line command.

@fanvinga commented on GitHub (Nov 4, 2019): This problem also exists for me. For me, the scenario that caused the issue was that I tried to copy the Dockerfile cross-line command to the Windows Terminal (WSL2), there would be extra blank lines, and bash would be recognized as a one-line command.
claunia commented 2026-01-30 23:54:46 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Nov 26, 2019):

Same issues with WT 0.7...

@angelog0 commented on GitHub (Nov 26, 2019): Same issues with WT 0.7...
claunia commented 2026-01-30 23:54:46 +00:00
Author
Owner
Copy Link

@fanvinga commented on GitHub (Nov 27, 2019):

A4FF48B2-B8EB-453F-A600-9F454C7ACF38
@angelog0 0.7.3291 seems to have solved the cross-row copy issue I complained about earlier

@fanvinga commented on GitHub (Nov 27, 2019): ![A4FF48B2-B8EB-453F-A600-9F454C7ACF38](https://user-images.githubusercontent.com/26292849/69683320-5f47f180-10ef-11ea-97d3-eb3a8044fb55.jpeg) @angelog0 0.7.3291 seems to have solved the cross-row copy issue I complained about earlier
claunia commented 2026-01-30 23:54:46 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Nov 29, 2019):

The issue seems related to TERM variable.

When one starts MSYS2 with the launcher msys2.exe, TERM results equal to xterm. In WT it is set to cygwin.

Now if I use in the WT profile

"commandline": "cmd.exe /c \"set TERM=xterm&& set MSYSTEM=MSYS&& set MSYS=winsymlinks:nativestrict&& C:/msys64/usr/bin/bash.exe --login\""

the issue seems fixed and the line is 130 craracters long but Emacs in terminal (msys/emacs 26.3-1) has issues: its window displays garbage and the colors are not so good.

@angelog0 commented on GitHub (Nov 29, 2019): The issue seems related to `TERM` variable. When one starts MSYS2 with the launcher `msys2.exe`, `TERM `results equal to `xterm`. In WT it is set to `cygwin`. Now if I use in the WT profile `"commandline": "cmd.exe /c \"set TERM=xterm&& set MSYSTEM=MSYS&& set MSYS=winsymlinks:nativestrict&& C:/msys64/usr/bin/bash.exe --login\""` the issue seems fixed and the line is 130 craracters long but Emacs in terminal (`msys/emacs 26.3-1`) has issues: its window displays garbage and the colors are not so good.
claunia commented 2026-01-30 23:54:46 +00:00
Author
Owner
Copy Link

@Biswa96 commented on GitHub (Nov 29, 2019):

How about TERM=xterm-256color?

@Biswa96 commented on GitHub (Nov 29, 2019): How about `TERM=xterm-256color`?
claunia commented 2026-01-30 23:54:46 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Nov 29, 2019):

No, it is worse.

For completeness, I have attached the result with MinTTY-TERM=xterm, WT-TERM=xterm, WT-TERM=xterm-256color. emacs-WT.tar.gz

@angelog0 commented on GitHub (Nov 29, 2019): No, it is worse. For completeness, I have attached the result with MinTTY-TERM=xterm, WT-TERM=xterm, WT-TERM=xterm-256color. [emacs-WT.tar.gz](https://github.com/microsoft/terminal/files/3906071/emacs-WT.tar.gz)
claunia commented 2026-01-30 23:54:47 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Dec 7, 2019):

For the sake of completeness, the issue is still active in the last 0.7.3382.0 WT release...

@angelog0 commented on GitHub (Dec 7, 2019): For the sake of completeness, the issue is still active in the last `0.7.3382.0` WT release...
claunia commented 2026-01-30 23:54:47 +00:00
Author
Owner
Copy Link

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

@angelog0 thank you. Since this isn’t a bug and requires actual investment to make the line wrapping feature work, we aren’t likely to fix it accidentally. We will definitely close this workitem when we know it to be complete.

@DHowett-MSFT commented on GitHub (Dec 7, 2019): @angelog0 thank you. Since this isn’t a bug and requires actual investment to make the line wrapping feature work, we aren’t likely to fix it accidentally. We will definitely close this workitem when we know it to be complete.
claunia commented 2026-01-30 23:54:47 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Mar 17, 2020):

Sorry, you have closed this

@msftbot bot closed this in #4415 19 days ago

but ALL defects I flagged here and here

are present in Windows Terminal Preview 0.10.761.0.

Are you sure you have rightly test the fix before to establish the issue was fixed?

BTW, #4415 is also cited here...

@angelog0 commented on GitHub (Mar 17, 2020): Sorry, you have closed this > @msftbot bot closed this in #4415 19 days ago but **ALL** defects I flagged [here](https://github.com/microsoft/terminal/issues/3367#issue-514015281) and [here](https://github.com/microsoft/terminal/issues/3367#issuecomment-548032259) are present in Windows Terminal Preview 0.10.761.0. Are you sure you have rightly test the fix before to establish the issue was fixed? BTW, #4415 is also cited [here](https://github.com/microsoft/terminal/releases/tag/v0.10.761.0)...
claunia commented 2026-01-30 23:54:47 +00:00
Author
Owner
Copy Link

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

Okay: as far as I can tell, your shell is inserting a manual line break one character before the console would word-wrap. It's inserting a literal manual line break, so there's no hope that WT can recover from that.

If I emit the contents of a long text file to the screen, it writes all the way up to the right edge and copies out of WT as a single line.

image

If the application emits its own newline because it misunderstood the size of the screen, it writes all the way up to the newline and copies out of WT as two lines.

image

As long as they're doing that, by literally telling us to break the line, there isn't anything we can do to repair it.

We've fixed all other known cases of broken line wrap on copy/paste.

@DHowett-MSFT commented on GitHub (Mar 17, 2020): Okay: as far as I can tell, your shell is inserting a manual line break one character before the console would word-wrap. It's inserting a literal manual line break, so there's no hope that WT can recover from that. If I emit the contents of a long text file to the screen, it writes all the way up to the right edge and _copies out of WT as a single line_. ![image](https://user-images.githubusercontent.com/14316954/76907696-21b8d100-6864-11ea-952f-eab24ce952fa.png) If the application emits its own newline because it misunderstood the size of the screen, it writes all the way up to the newline and _copies out of WT as two lines_. ![image](https://user-images.githubusercontent.com/14316954/76907736-39905500-6864-11ea-896b-8aa86a4009d6.png) As long as they're doing that, by literally telling us to break the line, there isn't anything we can do to repair it. We've fixed all other known cases of broken line wrap on copy/paste.
claunia commented 2026-01-30 23:54:47 +00:00
Author
Owner
Copy Link

@angelog0 commented on GitHub (Mar 18, 2020):

@DHowett-MSFT you are missing that only in WT that occurs. In MinTTY and other terminals copy/past of long lines works as expected. Admitting your conclusions would admit that WT is not usable as terminal with MSYS2 and friends. Maybe I will switch back to MinTTY because this is an issue tha causes many trouble to me.

@angelog0 commented on GitHub (Mar 18, 2020): @DHowett-MSFT you are missing that only in WT that occurs. In MinTTY and other terminals copy/past of long lines works as expected. Admitting your conclusions would admit that WT is not usable as terminal with MSYS2 and friends. Maybe I will switch back to MinTTY because this is an issue tha causes many trouble to me.
claunia commented 2026-01-30 23:54:48 +00:00
Author
Owner
Copy Link

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

I can't help that msys has a special contract with MinTTY. If you do this in the traditional windows console, it has the same behavior. This is 100% an application bug.

image

Conhost has supported line wrapping for five years -- it also works for every other application that correctly prints to the edge of the screen. It might be time for MSYS to reconsider how it interacts with the console.

@DHowett-MSFT commented on GitHub (Mar 18, 2020): I can't help that _msys has a special contract with MinTTY_. If you do this in the _traditional windows console_, it has the same behavior. This is 100% an application bug. ![image](https://user-images.githubusercontent.com/14316954/77016386-ba1e8680-6934-11ea-9ab7-9dc6c67b0810.png) Conhost has supported line wrapping for _five years_ -- it also works for every other application that correctly prints to the edge of the screen. It might be time for MSYS to reconsider how it interacts with the console.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-TerminalControl Issue-Task Priority-2 Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#4712
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?