DECCOLM escape sequence doesn't work #252

Closed
opened 2026-01-30 21:46:55 +00:00 by claunia · 4 comments
Owner

Originally created by @j4james on GitHub (May 7, 2018).

  • Your Windows build number:

Microsoft Windows [Version 10.0.16299.371]

  • What you're doing and what's happening:

I'm trying to switch between 80 and 132 columns with the DECCOLM escape sequence (ESC [ ? 3 h), and although it clears the screen and resets the cursor position, it appears to have no effect on the actual width of the screen. This is my test case to enable 132 columns:

printf "\e[?3h"

After poking around in the code a bit, I noticed there is a test at the start of the AdaptDispatch::SetColumns method, which stops the call from have any effect if the member variable at offset 30h is false (which it is). If I manually set that value to true then the call works.

I thought this might mean the DECCOLM functionality was disabled by default (as it is in XTerm), but I couldn't see any option in the console properties that would enable it, and Windows doesn't seem to support the escape sequence that XTerm uses to enable it (ESC [ ? 40 h).

I should also mention that even when the SetColumn call is working, it doesn't actually function as I would it expect it to. Both XTerm and Gnome Terminal resize the actual window when the DECCOLM mode is toggled, but the Windows console just alters the buffer width, leaving the window size unchanged. Having those two widths out of sync introduces a whole host of other problems.

  • What's wrong / what should be happening instead:

When the DECCOLM mode is set, I'd expect the screen width to change to 132. When it is reset, I'd expect the screen width to change to 80.

Originally created by @j4james on GitHub (May 7, 2018). * Your Windows build number: Microsoft Windows [Version 10.0.16299.371] * What you're doing and what's happening: I'm trying to switch between 80 and 132 columns with the DECCOLM escape sequence (`ESC [ ? 3 h`), and although it clears the screen and resets the cursor position, it appears to have no effect on the actual width of the screen. This is my test case to enable 132 columns: printf "\e[?3h" After poking around in the code a bit, I noticed there is a test at the start of the `AdaptDispatch::SetColumns` method, which stops the call from have any effect if the member variable at offset 30h is false (which it is). If I manually set that value to true then the call works. I thought this might mean the DECCOLM functionality was disabled by default (as it is in XTerm), but I couldn't see any option in the console properties that would enable it, and Windows doesn't seem to support the escape sequence that XTerm uses to enable it (`ESC [ ? 40 h`). I should also mention that even when the SetColumn call is working, it doesn't actually function as I would it expect it to. Both XTerm and Gnome Terminal resize the actual window when the DECCOLM mode is toggled, but the Windows console just alters the buffer width, leaving the window size unchanged. Having those two widths out of sync introduces a whole host of other problems. * What's wrong / what should be happening instead: When the DECCOLM mode is set, I'd expect the screen width to change to 132. When it is reset, I'd expect the screen width to change to 80.
claunia added the Issue-FeatureProduct-ConhostResolution-Fix-AvailableArea-VT labels 2026-01-30 21:46:55 +00:00
Author
Owner

@zadjii-msft commented on GitHub (May 7, 2018):

You're right, that functionality is actually disabled right now. I can't remember what at the moment, but we had to disable the resizing, and I added a backlog task to make it into a real setting. Only thing really stopping me is the fact that the current settings UI makes it fairly hard to another property.

For m records, this is MSFT:10086990

Thanks for calling out that it only changes the buffer, not the viewport, that'll be important to fix when I get to that.

@zadjii-msft commented on GitHub (May 7, 2018): You're right, that functionality is actually disabled right now. I can't remember what at the moment, but we had to disable the resizing, and I added a backlog task to make it into a real setting. Only thing really stopping me is the fact that the current settings UI makes it fairly hard to another property. For m records, this is MSFT:10086990 Thanks for calling out that it only changes the buffer, not the viewport, that'll be important to fix when I get to that.
Author
Owner

@j4james commented on GitHub (Jun 21, 2019):

Instead of worrying about getting an option added to the settings, could we not just implement the escape sequence I mentioned above that XTerm uses (ESC [ ? 40 h)? I've had a look at the code for this and it looks like it's an easy fix. The _fIsSetColumnsEnabled flag is already there, so it just needs a new method to set it, and a call from the _PrivateModeParamsHelper method to trigger it. As far as I can tell, you've already fixed whatever the problem was with the viewport not being sized.

And once this escape sequence is supported, a bunch of the 132 column tests in Vttest will immediately start working (or at least working better), because Vttest enables this option on startup - it has to for XTerm to work.

So what do you think? Should I submit a PR for this, or do you have other plans for how you want to handle it?

@j4james commented on GitHub (Jun 21, 2019): Instead of worrying about getting an option added to the settings, could we not just implement the escape sequence I mentioned above that XTerm uses (`ESC [ ? 40 h`)? I've had a look at the code for this and it looks like it's an easy fix. The `_fIsSetColumnsEnabled` flag is already there, so it just needs a new method to set it, and a call from the `_PrivateModeParamsHelper` method to trigger it. As far as I can tell, you've already fixed whatever the problem was with the viewport not being sized. And once this escape sequence is supported, a bunch of the 132 column tests in Vttest will immediately start working (or at least working better), because Vttest enables this option on startup - it has to for XTerm to work. So what do you think? Should I submit a PR for this, or do you have other plans for how you want to handle it?
Author
Owner

@DHowett-MSFT commented on GitHub (Jul 26, 2019):

Good news! This was released for the in-box console with insider build 18945!

@DHowett-MSFT commented on GitHub (Jul 26, 2019): Good news! This was released for the _in-box console_ with insider build 18945!
Author
Owner

@ghost commented on GitHub (Aug 3, 2019):

:tada:This issue was addressed in #1709, which has now been successfully released as Windows Terminal Preview v0.3.2142.0.🎉

Handy links:

@ghost commented on GitHub (Aug 3, 2019): :tada:This issue was addressed in #1709, which has now been successfully released as `Windows Terminal Preview v0.3.2142.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.3.2142.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?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#252