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

\b doesn't go all the way back on wrapped lines #19871

New Issue
Closed
opened 2026-01-31 06:55:54 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 06:55:54 +00:00
Owner
Copy Link

Originally created by @DannyDaemonic on GitHub (May 13, 2023).

Windows Terminal version

1.16.10261.0

Windows build number

Version 10.0.19045.2965

Other Software

No response

Steps to reproduce

It's easily reproducible in C. This seems to happen with any writing to the console, WriteConsole, printf, putchar, etc. Just write more letters than you have columns, and try to backspace back. You'll get stuck at the front of a row.

    for (int i = 0; i < 100; i++) {
        putchar('-');
    }
    for (int i = 0; i < 100; i++) {
        putchar('\b');
    }

Expected Behavior

I just want \b to take me back to the previous line if I didn't end the previous line with a \n. The console knows the line is wrapped. I can increase the size of the window and the cursor will pop back up to the previous line.

Actual Behavior

The cursor just gets stuck in the first column and refuses to delete what it just wrote.

I don't even care if it stops working when you end your line with a new line, but not letting you unwrap a line you know is wrapped? This is really hard to code around. You can't just write to the terminal, you have to query your position every time you want to backspace or line wrapping will break your program.

Originally created by @DannyDaemonic on GitHub (May 13, 2023). ### Windows Terminal version 1.16.10261.0 ### Windows build number Version 10.0.19045.2965 ### Other Software _No response_ ### Steps to reproduce It's easily reproducible in C. This seems to happen with any writing to the console, `WriteConsole`, `printf`, `putchar`, etc. Just write more letters than you have columns, and try to backspace back. You'll get stuck at the front of a row. ``` for (int i = 0; i < 100; i++) { putchar('-'); } for (int i = 0; i < 100; i++) { putchar('\b'); } ``` ### Expected Behavior I just want `\b` to take me back to the previous line if I didn't end the previous line with a `\n`. The console *knows* the line is wrapped. I can increase the size of the window and the cursor will pop back up to the previous line. ### Actual Behavior The cursor just gets stuck in the first column and refuses to delete what it just wrote. I don't even care if it stops working when you end your line with a new line, but not letting you unwrap a line you know is wrapped? This is really hard to code around. You can't just write to the terminal, you have to query your position every time you want to backspace or line wrapping will break your program.
claunia added the Needs-TriageIssue-Bug labels 2026-01-31 06:55:55 +00:00
claunia commented 2026-01-31 06:55:56 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (May 13, 2023):

This is expected behavior for a standard VT terminal. Quoting from the DEC STD 070 Reference Manual for the Back Space control (page 5-63):

The BS control is not affected in any way by the setting of Auto Wrap Mode. Under no circumstances does the Active Position advance to the previous line on reaching the beginning of the Active Line.

@j4james commented on GitHub (May 13, 2023): This is expected behavior for a standard VT terminal. Quoting from the DEC STD 070 Reference Manual for the Back Space control (page 5-63): > The BS control is not affected in any way by the setting of Auto Wrap Mode. Under no circumstances does the Active Position advance to the previous line on reaching the beginning of the Active Line.
claunia commented 2026-01-31 06:55:56 +00:00
Author
Owner
Copy Link

@DannyDaemonic commented on GitHub (May 13, 2023):

It's just really terribly inconvenient to never know if you can use \b. A lot of modern terminals do allow you to unwrap with backspace. I know PuTTY does this and I have a friend who uses iterms2 on macOS that allows it. The Gnome terminal does. I don't know if it really breaks anything since so many modern terminals allow it.

It's too bad the DEC standard made that call, but standards aren't always set in stone and can evolve over time to better serve user needs. I mean, back then they had things like ENQ, ACK, BEL, etc that are all but ignored these days. I took a look real quick and there's lot of stuff that have been left behind from the standard. Here's a direct quote stating double width lines are a required feature:

Page 1-18

1.6.2 Required Functions

The following controls are required for all conforming Level 1 implementations. 
...
SINGLE WIDTH LINE
DOUBLE WIDTH LINE
DOUBLE HEIGHT LINE TOP
DOUBLE HEIGHT LINE BOTTOM

I've never even heard of that before. And it's not just on that one page, double width lines are mentioned 26 times. But I'd be willing to bet no one meets that requirement anymore.

I doubt they ever imagined terminals that were vastly different sizes or that could change size on the fly. I'm not saying the DEC STD 070 standard isn't still influential, but terminal emulator developers do make practical decisions about what aspects to implement based on the needs and constraints of modern computing.

@DannyDaemonic commented on GitHub (May 13, 2023): It's just really terribly inconvenient to never know if you can use `\b`. A lot of modern terminals do allow you to unwrap with backspace. I know PuTTY does this and I have a friend who uses iterms2 on macOS that allows it. The Gnome terminal does. I don't know if it really breaks anything since so many modern terminals allow it. It's too bad the DEC standard made that call, but standards aren't always set in stone and can evolve over time to better serve user needs. I mean, back then they had things like ENQ, ACK, BEL, etc that are all but ignored these days. I took a look real quick and there's lot of stuff that have been left behind from the standard. Here's a direct quote stating double width lines are a required feature: Page 1-18 ``` 1.6.2 Required Functions The following controls are required for all conforming Level 1 implementations. ... SINGLE WIDTH LINE DOUBLE WIDTH LINE DOUBLE HEIGHT LINE TOP DOUBLE HEIGHT LINE BOTTOM ``` I've never even heard of that before. And it's not just on that one page, double width lines are mentioned 26 times. But I'd be willing to bet no one meets that requirement anymore. I doubt they ever imagined terminals that were vastly different sizes or that could change size on the fly. I'm not saying the DEC STD 070 standard isn't still influential, but terminal emulator developers do make practical decisions about what aspects to implement based on the needs and constraints of modern computing.
claunia commented 2026-01-31 06:55:56 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (May 14, 2023):

I know PuTTY does this and I have a friend who uses iterms2 on macOS that allows it. The Gnome terminal does.

I've just done some testing, and yes PuTTY does this, and so does iTerm2, but the only other terminal I could find that matches that behavior is Rxvt (but not all versions). Gnome Terminal does NOT wrap back onto the previous line. Nor does XTerm. Nor did any of the other 30 or so terminals I tested. I can't imagine we'd choose to side with PuTTY, iTerm2, and Rxvt over everyone else, in addition to ignoring the standard.

double width lines are mentioned 26 times. But I'd be willing to bet no one meets that requirement anymore.

You'd lose that bet. Windows Terminal and Conhost both support it, as does XTerm, MLTerm, Konsole, and like 15 or so other terminals that I'm aware of. I know not everyone cares about standards, but I certainly do, and I would like to improve our standards compliance - not make it worse.

@j4james commented on GitHub (May 14, 2023): > I know PuTTY does this and I have a friend who uses iterms2 on macOS that allows it. The Gnome terminal does. I've just done some testing, and yes PuTTY does this, and so does iTerm2, but the only other terminal I could find that matches that behavior is Rxvt (but not all versions). Gnome Terminal does NOT wrap back onto the previous line. Nor does XTerm. Nor did any of the other 30 or so terminals I tested. I can't imagine we'd choose to side with PuTTY, iTerm2, and Rxvt over _everyone_ else, in addition to ignoring the standard. > double width lines are mentioned 26 times. But I'd be willing to bet no one meets that requirement anymore. You'd lose that bet. Windows Terminal and Conhost both support it, as does XTerm, MLTerm, Konsole, and like 15 or so other terminals that I'm aware of. I know not everyone cares about standards, but I certainly do, and I would like to _improve_ our standards compliance - not make it worse.
claunia commented 2026-01-31 06:55:57 +00:00
Author
Owner
Copy Link

@DannyDaemonic commented on GitHub (May 14, 2023):

I realize I'm not likely to change your mind, but I'm still interested in the conversation.

The terminals that the DEC STD 070 standards were written for had a fixed width in characters. So you could write your code assuming you had, say, 80 characters. You send a string of text you decided on ahead of time and then safely backspace over it and overwrite it. For example, you could print "Loading..." and then send 10 BS before replacing it with "Successfully loaded."

However, a modern terminal could be just 4 columns wide! Without backspace unwrapping, the previous example is no longer safe. There's no string short enough to safely use backspaces with. You have to check your position every single time you want to backspace and have special code that will take you to the end of the line above your current row instead. I think it's important to keep these interfaces usable and efficient.

I ended up writing my own version of printf/WriteConsole that iterates over each character and handles backspaces differently. So, I guess technically the problem is solved for me, but I don't think the standard would have even introduced a special BS character if they thought it was going to be unreliable.

I can't imagine we'd choose to side with PuTTY, iTerm2, and Rxvt over everyone else

Is it really only those 3? I often run in a screen session so I may have overestimated how common it is since screen supports backspace unwrapping as well. I can't recall screen breaking anything by allowing this, but my point was just that it's already being done. Since some popular terminal emulators allow it, there's already reasonable support for the feature.

You'd lose that bet. Windows Terminal and Conhost both support it

I guess I would lose that bet! I doubt any real terminal supports it but it looks like some virtual terminals do. Even PuTTY supports this:

echo -e "\033#3This is the top half of a double-height line.\n\033#4This is the bottom half of a double-height line."`

I saw screenshots of it in Windows Terminal but I couldn't get it to work myself. How can I test it there? I tried:

Write-Host ([char]27 + "#3This is the top half of a double-height line.`n" + [char]27 + "#4This is the bottom half of a double-height line.")

But perhaps that was a bad example. There's also extensive discussion about printers in DEC STD 070 that I assume no one follows anymore. The word "printer" comes up 852 times. As technology advances and changes, it's only natural that certain parts of these standards become outdated. (Again, a terminal with 4 columns.) I realize there must be some trade off for moving forward but it does seem others have figured out how to do this effectively without breaking backward compatibility with existing command-line tools, scripts, etc.

@DannyDaemonic commented on GitHub (May 14, 2023): I realize I'm not likely to change your mind, but I'm still interested in the conversation. The terminals that the DEC STD 070 standards were written for had a fixed width in characters. So you could write your code assuming you had, say, 80 characters. You send a string of text you decided on ahead of time and then safely backspace over it and overwrite it. For example, you could print "Loading..." and then send 10 BS before replacing it with "Successfully loaded." However, a modern terminal could be just 4 columns wide! Without backspace unwrapping, the previous example is no longer safe. There's no string short enough to safely use backspaces with. You have to check your position every single time you want to backspace and have special code that will take you to the end of the line above your current row instead. I think it's important to keep these interfaces usable and efficient. I ended up writing my own version of printf/WriteConsole that iterates over each character and handles backspaces differently. So, I guess technically the problem is solved for me, but I don't think the standard would have even introduced a special BS character if they thought it was going to be unreliable. > I can't imagine we'd choose to side with PuTTY, iTerm2, and Rxvt over everyone else Is it really only those 3? I often run in a `screen` session so I may have overestimated how common it is since screen supports backspace unwrapping as well. I can't recall screen breaking anything by allowing this, but my point was just that it's already being done. Since some popular terminal emulators allow it, there's already reasonable support for the feature. > You'd lose that bet. Windows Terminal and Conhost both support it I guess I would lose that bet! I doubt any real terminal supports it but it looks like some virtual terminals do. Even PuTTY supports this: ```bash echo -e "\033#3This is the top half of a double-height line.\n\033#4This is the bottom half of a double-height line."` ``` I saw screenshots of it in Windows Terminal but I couldn't get it to work myself. How can I test it there? I tried: ```powershell Write-Host ([char]27 + "#3This is the top half of a double-height line.`n" + [char]27 + "#4This is the bottom half of a double-height line.") ``` But perhaps that was a bad example. There's also extensive discussion about printers in DEC STD 070 that I assume no one follows anymore. The word "printer" comes up 852 times. As technology advances and changes, it's only natural that certain parts of these standards become outdated. (Again, a terminal with 4 columns.) I realize there must be some trade off for moving forward but it does seem others have figured out how to do this effectively without breaking backward compatibility with existing command-line tools, scripts, etc.
claunia commented 2026-01-31 06:55:58 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 14, 2023):

(I'm going to move this to a discussion - it doesn't seem like there's anything for us to do on our end here, but this has been a really interesting discussion so by all accounts, do go on)

@zadjii-msft commented on GitHub (May 14, 2023): (I'm going to move this to a discussion - it doesn't seem like there's anything for us to do on our end here, but this has been a really interesting discussion so by all accounts, do go on)
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 Issue-Bug Needs-Triage
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#19871
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?