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

ANSI control code for line wrapping not supported? #11589

New Issue
Closed
opened 2026-01-31 02:51:55 +00:00 by claunia · 4 comments
claunia commented 2026-01-31 02:51:55 +00:00
Owner
Copy Link

Originally created by @patriksvensson on GitHub (Nov 25, 2020).

Not sure if I'm doing something wrong or not, but I can't get line wrapping to work, which wants me to know whether or not DECAWM support is supported at all in Windows Terminal.

I'm not sure if I'm doing something wrong, but it feels like I've tried everything I can think of.

Environment

Windows build number: 10.0.19041.0
Windows Terminal version (if applicable): 1.4.3243.0

Steps to reproduce

Open a PowerShell prompt and run the following script:

# Disable line wrapping
Write-Host "$([char]27)[?7l" -NoNewline

# First line
For ($i=0; $i -lt $host.UI.RawUI.BufferSize.Width ; $i++) {
    Write-Host '1' -NoNewline
}

# New line
Write-Host ""

# Second line
For ($i=0; $i -lt $host.UI.RawUI.BufferSize.Width; $i++) {
    Write-Host '2' -NoNewline
}

Expected behavior

I expect lines to "stay in place" without wrapping when I resize the window.

11111111111111111111111111111111111
22222222222222222222222222222222222

Actual behavior

Lines autowrap when I resize the window.

1111111111111111111111111111111111122222222222222222222222222222222222
Originally created by @patriksvensson on GitHub (Nov 25, 2020). Not sure if I'm doing something wrong or not, but I can't get line wrapping to work, which wants me to know whether or not [DECAWM support](https://vt100.net/docs/vt510-rm/DECAWM.html) is supported at all in Windows Terminal. I'm not sure if I'm doing something wrong, but it feels like I've tried everything I can think of. # Environment ```none Windows build number: 10.0.19041.0 Windows Terminal version (if applicable): 1.4.3243.0 ``` # Steps to reproduce Open a PowerShell prompt and run the following script: ```powershell # Disable line wrapping Write-Host "$([char]27)[?7l" -NoNewline # First line For ($i=0; $i -lt $host.UI.RawUI.BufferSize.Width ; $i++) { Write-Host '1' -NoNewline } # New line Write-Host "" # Second line For ($i=0; $i -lt $host.UI.RawUI.BufferSize.Width; $i++) { Write-Host '2' -NoNewline } ``` # Expected behavior I expect lines to "stay in place" without wrapping when I resize the window. ``` 11111111111111111111111111111111111 22222222222222222222222222222222222 ``` # Actual behavior Lines autowrap when I resize the window. ``` 1111111111111111111111111111111111122222222222222222222222222222222222 ```
claunia commented 2026-01-31 02:51:56 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Nov 25, 2020):

So, this one is interesting! Two different issues:

We landed support for DECAWM in #3943 (yay!), and it's got tests and I can validate that it works.
It seems as though Windows PowerShell does its own console mode manipulation that causes disabled auto-wrap to operate unexpectedly. Here's a side-by-side comparison between PowerShell (Windows) and PowerShell (Linux). Windows is in the front.

image

This looks like a C# System.Console issue. This part is Resolution-External.

Second:

DECAWM was specified before terminals could resize. As defined, it only determines whether the cursor moves to the next line when you go off the edge of the screen. This has no impact on whether reflowing resize will re-wrap that line when it is printed properly.

This part is Resolution-By-Design 😄

Thanks!

@DHowett commented on GitHub (Nov 25, 2020): So, this one is interesting! Two different issues: We landed support for `DECAWM` in #3943 (yay!), and it's got tests and I can validate that it works. It _seems_ as though Windows PowerShell does its own console mode manipulation that causes disabled auto-wrap to operate unexpectedly. Here's a side-by-side comparison between PowerShell (Windows) and PowerShell (Linux). Windows is in the front. ![image](https://user-images.githubusercontent.com/189190/100290697-d5fd1200-2f30-11eb-97d9-ec8aa8429c11.png) This looks like a C# `System.Console` issue. This part is `Resolution-External`. Second: DECAWM was specified before terminals _could_ resize. As defined, it _only_ determines whether the cursor moves to the next line when you go off the edge of the screen. This has no impact on whether reflowing resize will re-wrap that line when it is printed properly. This part is `Resolution-By-Design` :smile: Thanks!
claunia commented 2026-01-31 02:51:56 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Nov 25, 2020):

Admittedly, the unwrapping behavior you’re seeing is more likely because of the first part (powershell doing something strange) since the lines written there would—if DECAWM were working—be emitted with no wrap flag.

@DHowett commented on GitHub (Nov 25, 2020): Admittedly, the unwrapping behavior you’re seeing is more likely because of the first part (powershell doing something strange) since the lines written there would—if DECAWM were working—be emitted with no wrap flag.
claunia commented 2026-01-31 02:51:57 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 26, 2020):

For the record, I don't think our wrapping behaviour is correct, and I had been meaning to propose changing it at some point. As it's currently implemented, if you output a character on the last column of the page, it marks that line as wrapped, even if you don't output any further characters. That seems very wrong to me.

In the past this may have been less of an issue, because the newline implementation in WriteCharsLegacy will reset the wrapped status of the line. However, when the VT newline handling got pulled out of WriteCharsLegacy I think we lost that behaviour. I'm not totally convinced resetting on newline was the correct thing to do anyway, but it at least mitigated the problem.

So unless we have legacy reasons for implementing wrapping the way it is now, I'd definitely suggest not setting the wrapped flag when writing in the last column, and only set if the output actually wraps onto the next line. As for unsetting the flag for things like newline, I'd want to see how other terminals handle that, and consider matching their behaviour if it seems reasonable.

@j4james commented on GitHub (Nov 26, 2020): For the record, I don't think our wrapping behaviour is correct, and I had been meaning to propose changing it at some point. As it's currently implemented, if you output a character on the last column of the page, it marks that line as wrapped, even if you don't output any further characters. That seems very wrong to me. In the past this may have been less of an issue, because the newline implementation in `WriteCharsLegacy` will reset the wrapped status of the line. However, when the VT newline handling got pulled out of `WriteCharsLegacy` I think we lost that behaviour. I'm not totally convinced resetting on newline was the correct thing to do anyway, but it at least mitigated the problem. So unless we have legacy reasons for implementing wrapping the way it is now, I'd definitely suggest _not_ setting the wrapped flag when writing in the last column, and only set if the output actually wraps onto the next line. As for unsetting the flag for things like newline, I'd want to see how other terminals handle that, and consider matching their behaviour if it seems reasonable.
claunia commented 2026-01-31 02:51:57 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Nov 26, 2020):

@j4james yeah, I was just messing around in this area (though on the other side: moving around the ownership of WasWrapForced). I'm convicted that we should never wrap ever unless a printable character that moves the carriage is emitted when the cursor is in the deferred EOL position.

I expect that this will become quite complicated when we want to support win32 applications that have come to work with wrapping but do not use EOL deferral.

@DHowett commented on GitHub (Nov 26, 2020): @j4james yeah, I was just messing around in this area (though on the other side: moving around the ownership of `WasWrapForced`). I'm convicted that we should never wrap ever _unless_ a printable character that moves the carriage is emitted when the cursor is in the deferred EOL position. I expect that this will become quite complicated when we want to support win32 applications that have come to work with wrapping but do not use EOL deferral.
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 Needs-Tag-Fix Needs-Triage Resolution-By-Design Resolution-External
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#11589
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?