> I'm none the wiser about your final sentence Microsoft has a [long history][1] of providing ANSI X3.64 terminal support — confusingly abbreviated "ANSI", as if that body only ever did one standard — that's slow, incomplete, missing, and/or late compared to its contemporary implementations, so that it's almost always better to use a third-party or hand-rolled solution rather than Microsoft's latest offering. Most recently, we see this in the assorted brokennesses of WSL1's terminal handling, which they're only just now beginning to correct with the combination of [WSL2][2] and [Windows Terminal][3]. As welcome an improvement as that last is over the stupendously creaky Windows Console, it's still [buggy and incomplete][4] with respect to the modern ANSI X3.64 descendants on Linux, BSD, and macOS. I bring up the other OSes not to tell you that you must switch to one of them to get this right but to point out that ANSI X3.64 has been built upon again and again by both *de jure* and *de facto* standards since the mid-1970s. Microsoft didn't even try to keep up with any of this from about 1988 (MS-DOS 4.0) to 2016 (WSL 1), so it has a whole lot of catching up to do. I predict that they'll never rival the likes of `xterm` given their history of incomplete support of standards developed elsewhere. …And all this happens in a world that has the [comprehensive `vttest` program][5] in it, so we can all agree on what is "correct." A subset test covering the cases I care about (§1-4, 11.5, 11.6, and 11.8.3 in `vttest` 2.7) results in a score of 104 on macOS 10.15's Terminal by my reckoning but 69 on Windows Terminal Preview Release. Microsoft lost most of those points by not supporting the 132-column and double-width modes, which lack you may wish to ignore, but there are several unrelated tests it also fails. I assume the "stable" version of Windows Terminal scores the same or worse. **EDIT 1:** I installed WSL 2 on a Windows 10 box I happened to have handy — not a normal condition for me — with VSCode and Microsoft's WSL Remote extension and repeated the above test. I get a score of about 61. There were actually a few things it did right relative to both Windows Terminal and Apple's Terminal.app, but on balance, it's missing features relative to them. Oh, and that score only applies if you're charitable and ignore its lack of blink support and dark/light mode switching. It'd be roughly in the 40s if you insisted on those features working. Windows Terminal and VSCode Terminal aren't the only option on Windows. There are third-party alternative terminals such as PuTTY/MinTTY and SecureCRT. This doesn't solve your VSCode problem, but it once again shows that many different organizations can score high on `vttest` while Microsoft lags. Bottom line: I completely fail to be stunned by the news that there's yet another piece of Microsoft software not getting this right. ---- P.S. to those unclear on what any of this has to do with SQLite: if you use a buggy terminal with SQLite, you can expect buggy terminal-related behavior from SQLite. ---- **EDIT 2:** All of these tests were done with the terminal resized to 80x24 to give it the best chance of earning points on each test. Most terminal emulators will cope reasonably well when run larger than this, but you can pretty much guarantee bad behavior when you run any X3.64 family terminal *smaller* than this. I'm posting this edit because I expect VSCode Terminal to regularly be run smaller than 80x24, on the height at least, so that's a further reason to expect brokenness here. [1]: https://en.wikipedia.org/wiki/ANSI_escape_code#DOS,_OS/2,_and_Windows [2]: https://docs.microsoft.com/en-us/windows/wsl/compare-versions [3]: https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk701 [4]: https://github.com/microsoft/terminal/issues?q=is%3Aissue+is%3Aopen+label%3AArea-VT [5]: https://invisible-island.net/vttest/