VsCode is both inconsistent and fails to work correctly in Windows for ANSI codes to reset the terminal scrollback buffers

[smallscript]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.76.0
• OS Version: Windows_NT x64 10.0.19045

Steps to Reproduce:

1. READ stack-overflow discussion of the issue. The problem-behavior has been discussed ad nauseum on the web; the StackOverflow answer referenced is the best concise summary.
2. Use any script to output the ANSI sequence '\ec\e[3J'
   • the above sequence works on wt.exe, OSX terminals, various ssh tools, VsCode on Mac BUT NOT on Windows.

pain-points
Noting that keyboard actions within VsCode do work to clear the buffers on windows ｢having that capability does not address the ANSI problem｣

• I.e., that does not allow a program/script the ability to clear the screen and buffers.
  • It is super-duper frustrating when repeatedly executing test cmds as the scrollback buffers make a confusing mess of the terminal output.
• It would be great if wt.exe was embedded into the terminal view as an option.
  • Doing so would also provide proper support for ANSI Hypertext Links which also do not
    work in VsCode but do work in wt.exe.
  • Doing so would also ensure the terminal state was properly restored between execution CLI programs that might
    leave it in an inconsistent state. (which is also an frustrating pain point during development).
• Or, alternately make the VsCode on Windows behavior consistent with Windows Terminal ANSI behavior.

[vscodenpa]

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.76.1. Please try upgrading to the latest version and checking whether this issue remains.

Happy Coding!

[meganrogge]

Same as #75141 re clearing the buffer on windows

[smallscript]

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.76.1. Please try upgrading to the latest version and checking whether this issue remains.

Happy Coding!

1.76.0 vs 1.76.1 makes no difference. That update came out a day or so ago. But, in any case, I upgraded 1.76.1 and it makes no difference in this issue.

[smallscript]

That issue was opened 4 years-ago...

vivekmalhotra opened this issue on Jun 8, 2019

The enhancements changes to wt.exe and many other CLI terminal tools have dramatically evolved since then for ANSI control-behavior support and tooling expectations for ANSI control-behavior support. :-)

[qtow]

I've noticed this problem on my work computer running Windows 10, but I don't think it occurs on either of my home computers running Windows 11. I don't have the patience to test this thoroughly, but it might be worth investigating what the difference there is. Possibly a newer conhost.exe? Can VSCode ship its own copy of the newer version, or something like that? I'm not sure how conhost.exe works or what it really even does, so that may be a nonsensical question.

I'd also like to point out that, as far as I understand, this issue is very different from the "Terminal: Clear" command issue(s).

[Tyriar]

This is tracked in xtermjs/xterm.js#1727

[qtow]

This is tracked in xtermjs/xterm.js#1727

That issue is about the behavior of \x1b[2J within xterm.js on all platforms. This issue is about the behavior of \x1b[3J on Windows 10. On Windows 10, \x1b[3J does nothing. On Windows 11, \x1b[3J appropriately clears the entire scrollback buffer. If you replace conhost.exe with OpenConsole.exe from a Windows Terminal release on a Windows 10 installation, \x1b[3J works appropriately. To test this yourself,

1. Create a Windows 10 VM
2. Download WindowsTerminal_1.17.11461.0_x64.zip
3. Open C:\Windows\System32\
4. Delete conhost.exe
   1. Right Click
   2. Properties
   3. Security
   4. Advanced
   5. Change
   6. "Administators"
   7. OK
   8. OK
   9. Edit
   10. Administrators
   11. Full Control
   12. 🗹 Allow
   13. OK
   14. Yes
   15. OK
   16. Right Click
   17. Delete
5. Drop the contents of WindowsTerminal_[...].zip into C:\Windows\System32\
6. Rename OpenConsole.exe to conhost.exe

You can print the typical ANSI escape codes for commands like clear with the following PowerShell snippet:

Write-Host -NoNewLine "`u{1b}[H`u{1b}[2J`u{1b}[3J"

This is CSI H, CSI 2 J, CSI 3 J - that's "Move cursor to row 1, column 1", "Clear screen", "Clear scrollback buffer". The third of those, CSI 3 J ("`u{1b}[3J"), is what does not work on Windows 10.

I'm not sure exactly what role(s) conhost.exe plays with respect to interpreting and handling ANSI escapes, so that's as far as I can narrow this issue down the issue.

[Tyriar]

I see, in that case it's an issue with an older version of conpty (one of the components in conhost.exe). The only fix here is to either update to Windows 11 or wait until we ship conpty with VS Code which could be some time as we're blocked on the Windows Terminal team to package it up for us to consume.

[qtow]

Would it be possible to let VS Code use an alternative conpty? E.g., allow users to point VS Code at a Windows Terminal installation and have it use the version of conpty provided there.

I'm unfortunately stuck on Windows 10 at work (well, I did find out that Windows will let me upgrade to 11, but I've yet to be brave enough to attempt that), and "we're blocked on the Windows Terminal team" isn't particularly helpful to end users.

Is there a separate issue / milestone / something else about shipping conpty with VS Code? If not, could we reopen this issue until it's fixed?

[Tyriar]

@qtow we want to, but we're blocked on their team. Here's the issue on their side microsoft/terminal#15065.

Upgrading to 11 isn't a big issue in my experience, you can move the taskbar back to the left if that's the scary thing like it was for me.

[qtow]

@qtow we want to, but we're blocked on their team. Here's the issue on their side microsoft/terminal#15065.

I understand you're blocked, I was wondering if a workaround could be introduced in the meantime. I'm not sure it would actually work, but I'm assuming conpty is statically linked into OpenConsole.exe, so maybe VS Code could open OpenConsole.exe as a library?

It looks like Visual Studio 2022 (possibly only the preview version) ships a build of OpenConsole.exe with a separate conpty.dll. I'm not sure how much effort it would be, but it seems to me like VS Code could copy whatever they're doing.

Upgrading to 11 isn't a big issue in my experience, you can move the taskbar back to the left if that's the scary thing like it was for me.

It's more so the heaps of legacy software that I'm not confident will continue to work. I'm generally fond of staying as up to date as possible on everything, but I really need my work computer to function as intended. The new Outlook UI is already proving quite annoying for various reasons, and that's just an email client.

[qtow]

microsoft/node-pty#490 is the issue that tracks actually embedding the conpty package once it's available.