-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for VT100 Auto Wrap Mode (DECAWM) #3943
Conversation
1039a3e
to
555e773
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one minor request comment before I'll sign.
Overall, I think this is fine. Thank you.
I want to get this in before I work on the boogaloo stream-writing fixes (#780) that are intended to replace WriteCharsLegacy. I'm a bit nervous about changing WriteCharsLegacy
and AdjustCursorPosition
here because they've historically been bug factories (which is why #780 is a thing). But I accept your justifications and mitigation of risk by scoping it to VT here.
If #780 is likely to happen soonish, I'm actually wondering now if we're better off leaving this PR for the time being, and then later reimplement it on top of the new stream writer? At that point, none of this code would be needed in |
Let's bring it in because it will guide the way I work. And I think these in conjunction with your C0 proposal will make #780 more self-evident. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
K looks good.
1e9d39c
to
febbbf8
Compare
febbbf8
to
0d8eb11
Compare
(╯‵□′)╯︵┻━┻ |
Going to try to re-run/merge until success. |
I thought I had it working, but it looks like I'm going to need to merge again or rebase. I have to go to sleep now, and I have work tomorrow, but will try again tomorrow evening or over the weekend. |
dc2bcdd
to
0c6944f
Compare
The merge looked super easy so I did it in the web editor. Marking AutoMerge. If build succeeds, we're good to go. |
Hello @miniksa! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
I think the web editor screws up line endings, which is something the code formatter now checks, and I suspect that is why it's failing. |
@miniksa Is it OK if I just force-push a rebase? I don't know how else to fix things at this point. |
@j4james that'll be fine. Sorry about that 😄 |
Yes, it's fine. Sorry, everyone stood in my office for like 45 minutes BSing so I didn't see this as it came in. Also, apologies that I keep learning bad merging lessons on your branches. |
…BLE_WRAP_AT_EOL_OUTPUT mode is set.
…P_AT_EOL_OUTPUT mode.
…patched correctly.
…ing is disabled in VT mode.
…mped appropriately for the mode.
680bd61
to
dc9a4b6
Compare
FYI, the current build failure is just the unit tests timing out, which seems to happen quite often in the CI build. I don't think there's actually anything wrong with the code itself. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Yeah , looking at this in #4384 |
WELP. |
🎉 Handy links: |
🎉 Once again, thanks for the contribution! This pull request was included in a set of conhost changes that was just |
Summary of the Pull Request
This adds support for the
DECAWM
private mode escape sequence, which controls whether or not the output wraps to the next line when the cursor reaches the right edge of the screen. Tested manually, with Vttest, and with some new unit tests.PR Checklist
Detailed Description of the Pull Request / Additional comments
The idea was to repurpose the existing
ENABLE_WRAP_AT_EOL_OUTPUT
mode, but the problem with that was it didn't work in VT mode - specifically, disabling it didn't prevent the wrapping from happening. This was because in VT mode theWC_DELAY_EOL_WRAP
behaviour takes affect, and that bypasses the usual codepath whereENABLE_WRAP_AT_EOL_OUTPUT
is checked,To fix this, I had to add additional checks in the
WriteCharsLegacy
function (7dbefe0) to make sure theWC_DELAY_EOL_WRAP
mode is only activated whenENABLE_WRAP_AT_EOL_OUTPUT
is also set.Once that was fixed, though, another issue came to light: the
ENABLE_WRAP_AT_EOL_OUTPUT
mode doesn't actually work as documented. According to the docs, "if this mode is disabled, the last character in the row is overwritten with any subsequent characters". What actually happens is the cursor jumps back to the position at the start of the write, which could be anywhere on the line.This seems completely broken to me, but I've checked in the Windows XP, and it has the same behaviour, so it looks like that's the way it has always been. So I've added a fix for this (9df9849), but it is only applied in VT mode.
Once that basic functionality was in place, though, we just needed a private API in the
ConGetSet
interface to toggle the mode, and then that API could be called from theAdaptDispatch
class when theDECAWM
escape sequence was received.One last thing was to reenable the mode in reponse to a
DECSTR
soft reset. Technically the auto wrap mode was disabled by default on many of the DEC terminals, and some documentation suggests thatDECSTR
should reset it to that state, But most modern terminals (including XTerm) expect the wrapping to be enabled by default, andDECSTR
reenables that state, so that's the behaviour I've copied.Validation Steps Performed
I've add a state machine test to confirm the
DECAWM
escape is dispatched correctly, and a screen buffer test to make sure the output is wrapped or clamped as appropriate for the two states.I've also confirmed that the "wrap around" test is now working correctly in the Test of screen features in Vttest.