Skip to content
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

DECCOLM escape sequence doesn't work #171

Closed
j4james opened this issue May 7, 2018 · 4 comments · Fixed by #1709
Closed

DECCOLM escape sequence doesn't work #171

j4james opened this issue May 7, 2018 · 4 comments · Fixed by #1709
Labels
Area-VT Virtual Terminal sequence support Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Conhost For issues in the Console codebase Resolution-Fix-Available It's available in an Insiders build or a release

Comments

@j4james
Copy link
Collaborator

j4james commented 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.

@zadjii-msft
Copy link
Member

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 zadjii-msft added Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. backlog labels May 7, 2018
@zadjii-msft zadjii-msft added this to the Backlog milestone May 7, 2018
@zadjii-msft zadjii-msft added Product-Conhost For issues in the Console codebase and removed console labels May 21, 2018
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@miniksa miniksa added Area-VT Virtual Terminal sequence support and removed Mass-Chaos labels May 17, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 18, 2019
@j4james
Copy link
Collaborator Author

j4james commented 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?

@ghost ghost added the In-PR This issue has a related PR label Jun 28, 2019
@ghost ghost added Needs-Tag-Fix Doesn't match tag requirements Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Jul 2, 2019
@DHowett-MSFT DHowett-MSFT added the Resolution-Fix-Available It's available in an Insiders build or a release label Jul 26, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jul 26, 2019
@DHowett-MSFT DHowett-MSFT removed the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label Jul 26, 2019
@DHowett-MSFT
Copy link
Contributor

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

@ghost
Copy link

ghost commented Aug 3, 2019

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

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-VT Virtual Terminal sequence support Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Conhost For issues in the Console codebase Resolution-Fix-Available It's available in an Insiders build or a release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants