Properly implement delayed EOL wrap in Terminal::_WriteBuffer #16713

Closed
opened 2026-01-31 05:20:24 +00:00 by claunia · 3 comments
Owner

Originally created by @carlos-zamora on GitHub (Feb 8, 2022).

This issue tracks implementing delayed EOL wrap for Terminal::_WriteBuffer. More details on the exact issue below.

This is a subset of or step towards #780.


The problem is just that the Terminal::_WriteBuffer method doesn't implement delayed EOL wrap. As a very simple test case, run printf "\e[999C*" with a breakpoint in the _WriteBuffer method. You'll see it write out the * character and then increment the X coordinate beyond the width of the page, passing that invalid value to _AdjustCursorPosition. That should never happen.

What it should be doing is recording the delayed wrap, and leaving the cursor where it is in the final column. You can see how it's handled in conhost here:

2b202ce6d9/src/host/_stream.cpp (L573-L588)

If more output is received after that, then the cursor will need to be moved to the start of the next line, before processing the output. Again you can see how that's handled in conhost here:

2b202ce6d9/src/host/_stream.cpp (L365-L376)

The bottom line is that WT doesn't have a fully functional WriteBuffer implementation - I think that's what #780 was meant to resolve.

Originally posted by @j4james in https://github.com/microsoft/terminal/issues/8730#issuecomment-1028921497

Originally created by @carlos-zamora on GitHub (Feb 8, 2022). This issue tracks implementing delayed EOL wrap for `Terminal::_WriteBuffer`. More details on the exact issue below. This is a subset of or step towards #780. - - - - - - - - - The problem is just that the `Terminal::_WriteBuffer` method doesn't implement delayed EOL wrap. As a very simple test case, run `printf "\e[999C*"` with a breakpoint in the `_WriteBuffer` method. You'll see it write out the `*` character and then increment the X coordinate beyond the width of the page, passing that invalid value to `_AdjustCursorPosition`. That should never happen. What it should be doing is recording the delayed wrap, and leaving the cursor where it is in the final column. You can see how it's handled in conhost here: https://github.com/microsoft/terminal/blob/2b202ce6d993404010337fe8ff205d7b240d60f5/src/host/_stream.cpp#L573-L588 If more output is received after that, then the cursor will need to be moved to the start of the next line, _before_ processing the output. Again you can see how that's handled in conhost here: https://github.com/microsoft/terminal/blob/2b202ce6d993404010337fe8ff205d7b240d60f5/src/host/_stream.cpp#L365-L376 The bottom line is that WT doesn't have a fully functional `WriteBuffer` implementation - I think that's what #780 was meant to resolve. _Originally posted by @j4james in https://github.com/microsoft/terminal/issues/8730#issuecomment-1028921497_
claunia added the Area-OutputResolution-Fix-CommittedIssue-TaskProduct-Terminal labels 2026-01-31 05:20:24 +00:00
Author
Owner

@carlos-zamora commented on GitHub (Feb 8, 2022):

@zadjii-msft wasn't sure which milestone to put this one in. This affects rendering too, so I feel like it should be more important than Backlog, but I don't think we'll be able to get to it in 1.12. 🤷

@carlos-zamora commented on GitHub (Feb 8, 2022): @zadjii-msft wasn't sure which milestone to put this one in. This affects rendering too, so I feel like it should be more important than `Backlog`, but I don't think we'll be able to get to it in 1.12. 🤷
Author
Owner

@zadjii-msft commented on GitHub (Feb 8, 2022):

I'm gonna toss this into 22H2, because I'm gonna guess this is part of the wild ride that is #5800. I'll put it there and make sure it won't just go away with #8000 later.

@zadjii-msft commented on GitHub (Feb 8, 2022): I'm gonna toss this into 22H2, because I'm gonna guess this is part of the wild ride that is #5800. I'll put it there and make sure it won't just go away with #8000 later.
Author
Owner

@ghost commented on GitHub (Jan 24, 2023):

:tada:This issue was addressed in #14640, which has now been successfully released as Windows Terminal Preview v1.17.1023.🎉

Handy links:

@ghost commented on GitHub (Jan 24, 2023): :tada:This issue was addressed in #14640, which has now been successfully released as `Windows Terminal Preview v1.17.1023`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.17.1023) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#16713