Vscode: Terminal: broken text layout

[warpdesign]

• VSCode Version: Code - Insiders 1.9.0-insider (fcac9b686abe4292e69a774f61c8c4ce17768bf5, 2017-01-31T00:57:46.157Z)
• OS Version: Windows_NT ia32 10.0.15019
• Extensions:

|Extension|Author|Version|
|---|---|---|
|vscode-eslint|dbaeumer|1.2.2|
|theme-dracula|dracula-theme|1.2.5|
|vscode-great-icons|emmanuelbeziat|1.1.38|
|Theme-azure|gerane|0.0.2|
|theme-material-theme|jprestidge|1.0.1|
|vs-color-picker|lihui|0.3.2|
|Theme-MaterialKit|ms-vscode|0.1.1|
|view-in-browser|qinjia|0.0.4|
|ActiveFileInStatusBar|RoscoP|1.0.2|
|eval|Stormspirit|0.0.5|
|omnipascal|Wosi|0.12.0|

---

Steps to Reproduce:

1. running grunt test to run unit testing should produce this output: (here in cmd.exe)

Here is what I got in VSCode integrated terminal:

Note that the first time I ran it, the layout of the prompt was also broken, instead of the cursor directly following the prompt, like:

I was having:

(and I could not move the cursor more on the left)

[Tyriar]

What's in your settings.json file and was there any errors in the dev tools console?

[warpdesign]

There were no errors in the console.

My settings.json file:

// Place your settings in this file to overwrite the default settings
{
    "terminal.integrated.cursorBlinking": true,
    "terminal.integrated.lineHeight": 1.3,
    "workbench.editor.enablePreview": false,
    "workbench.editor.enablePreviewFromQuickOpen": false,
    "window.openFilesInNewWindow": false,
    "window.reopenFolders": "one",
    "typescript.check.tscVersion": false,
    "workbench.sideBar.location": "left",
    "window.zoomLevel": 0,
    "workbench.activityBar.visible": true,
    "terminal.integrated.shell.windows": "C:\\WINDOWS\\Sysnative\\cmd.exe",
    "terminal.integrated.rightClickCopyPaste": false
}

[warpdesign]

Here is what the inspector looks like (notice the prompt that seems to get shifted to the right (the begining of the prompt's text is in the previous div). Hope this helps.

[warpdesign]

More information: this didn't happen with VSCode 1.8.1, but happens with the latest final 1.9 build as well.

Running a simple sudo apt-get install package is enough to trigger the problem:

[CaselIT]

I have the same issue, when using mocha to test something.
If needed I can add a simple repo to reproduce

Below is my configuration:

• VSCode Version: Code 1.9.0 (27240e71ef390bf2d66307e677c2a333cebf75af, 2017-02-02T08:31:00.827Z)
• OS Version: Windows_NT ia32 10.0.15019
• Extensions:

|Extension|Author|Version|
|---|---|---|
|python|donjayamanne|0.5.8|
|tslint|eg2|0.8.1|
|docthis|joelday|0.3.10|
|PowerShell|ms-vscode|0.9.0|
|typescript-javascript-grammar|ms-vscode|0.0.18|

[CaselIT]

I've noticed that both @waderyan and me are running Windows 10 preview 15019.
I've tried to reproduce it on a normal version of windows 10 and could not. So the fault may be in the preview of windows.

Below is the configuration of my other machine where I could not reproduce the bug

• VSCode Version: Code 1.9.0 (27240e71ef390bf2d66307e677c2a333cebf75af, 2017-02-02T08:31:00.827Z)
• OS Version: Windows_NT ia32 10.0.14393
• Extensions:

|Extension|Author|Version|
|---|---|---|
|python|donjayamanne|0.5.6|
|tslint|eg2|0.8.1|
|vscode-npm-script|eg2|0.1.8|
|docthis|joelday|0.3.10|
|vscode-filesize|mkxml|1.0.0|
|PowerShell|ms-vscode|0.9.0|
|typescript-javascript-grammar|ms-vscode|0.0.18|

Hope it helps

[CaselIT]

I'm able to reproduce it on another pc with windows 15019

[Tyriar]

This could be related to the terminal not printing unicode characters correctly https://github.com/Microsoft/vscode/issues/19763? If you can reproduce what locale are you using? Could you also post a screenshot of VS Code terminal bad output via good output in cmd?

[CaselIT]

My locale is us. The normal terminal works fine

I've noticed that the problem occurs only when the terminal is larger than about 1200px see images:
Here is fine and the terminal is 1208px

here it does not render correctly, the size is 1240px

(my screen size is 1440p, so 2560px horizontally )
Let me know if you need some other tests

[CaselIT]

Also resizing the window horizontally causes multiple times randomly problems
In the output below is should be as in the images in the previous post

[Tyriar]

Do you see the problem only after resizing? Maybe related to https://github.com/Microsoft/vscode/issues/8336

[CaselIT]

The one in the last image yes.
The other problems are always there if the terminal is larger than about 1200px. (I don't know if the measure is connected to the screen resolution)

[CaselIT]

I've tried on my other pc, that has a screen of 1600x900px and the behavior is the same, above about 1200px the terminal has problems.

[CaselIT]

I've updated on v1.9.1 and the issue is still there.

[warpdesign]

Update: I'm still having the problem with latest VSCode insider (2017-02-10T07:10:40.518Z) & latest Windows 10 insider build (15031).

[asvetliakov]

Actually the terminal is unusable for me:

[fess932]

Actually the terminal is unusable for me too:

[CaselIT]

@fess932 @asvetliakov are you both using win 10 preview like me and @warpdesign ?

[fess932]

@CaselIT Yes. This problem is only in win 10 preview?

[CaselIT]

It appears to be from the people on this issue. Also I've tries using same vscode version and the same terminal command and on the preview I have the problem while on the normal win10 version I have not.

[warpdesign]

@CaselIT @fess932 I am using win 10 preview too.

Note that with cmd.exe there are no such problems.

[CaselIT]

Note that with cmd.exe there are no such problems.

Sadly I have them also using cmd.

[warpdesign]

@Tyriar What's the status of this bug? Do you need more information?

It really makes the terminal difficult to use since most commands will break the output like this.

It seems to happen only in insider builds but the final "Creators Update" update is supposed to be released in a few weeks only.

[Tyriar]

@warpdesign I haven't been able to repro, if it's related to Insiders then that's the reason.

@miniksa @bitcrazed any idea what this could be related to? It only appears to happen on Window Insiders.

[bitcrazed]

@Tyriar This also appears to repro in 14393 as per @CaselIT's report above.

Struggling to repro here.

Can someone pipe command output into a file that can be echoed locally to repro? Or perhaps provide a minimalist repro?

[CaselIT]

@bitcrazed I've just tried on win10 15042 and it still has the problem.

Regarding how to reproduce the mocha output always breaks it for me, so it should be sufficient to write some fake tests. If you can't reproduce it, I'll try to set up a repo to reproduce later or tomorrow

[CaselIT]

I've added a repo
https://github.com/CaselIT/vscode-bug-19665

As mentioned before and also in the repo readme if the terminal windows is smaller than ~1200px everything works fine

[CaselIT]

Just tried vscode 1.10.1 and I have the same issue

[warpdesign]

@bitcrazed Here is an exemple file.

I ran sudo apt-get install <some non existing package> and this was enough to break the layout.

Here is the output of the command (doing cat test.txt is enough to break the layout here).

test.txt

I am using the latest insider build (15046) and the latest VSCode insider build.

[warpdesign]

Here is a screenshot of the problem, running cat test.txt on VSCode terminal and cmd.exe:

I confirm that depending on the VSCode window size the problem may not appear. With cmd.exe it always works as expected, no matter the size of the window.

[warpdesign]

More information: looking at the test.txt file, it seems the ellipsis utf8 character is encoded using 3 bytes (0xE280A6), see http://www.fileformat.info/info/unicode/char/2026/index.htm

And this may be the problem: pasting this character several times directly in the VSCode terminal is enough to trigger the problem.

Simply try to copy/paste this ……………………………… and you'll see the cursor gets shifted to the right.

Here is what the inspector shows after pasting this:

Maybe comparing it to what you get on non-insider Windows builds could help ?

[bitcrazed]

This definitely looks like something for @Tyriar & the VSCode team to take a look at.

[Tyriar]

Thanks for looking into it @bitcrazed :smiley:

[Tyriar]

I can repro, I found this only happens when the terminal really wide.

[Tyriar]

Here's a snapshot of what's send to xterm.js (looks like the problem is in node-pty):

Narrow:

Wide:

[Tyriar]

This was introduced in v1.9 where the big Windows improvements came in https://code.visualstudio.com/updates/v1_9#_integrated-terminal-improvements, this is probably an upstream issue.

[Tyriar]

It appears to happen when the terminal is sized to 160 characters wide or more. @rprichard I'm guessing this is related to winpty, does this number have any significance in winpty? I could restrict the size of the terminal to <= 159 characters but would prefer to fix the root cause if possible.

TLDR, this is happening when running certain things in the terminal:

https://github.com/Microsoft/vscode/issues/19665#issuecomment-285973782 shows what is sent from node-pty to xterm.js

[Tyriar]

Search of '160' in winpty: https://github.com/rprichard/winpty/search?utf8=%E2%9C%93&q=160

[Tyriar]

I capped terminal cols at 159 characters on Windows for the time being https://github.com/Microsoft/vscode/commit/4709fcaf35acc19fe321885f24e224da5a078e24, you should get this workaround in the next Insiders build.

[rprichard]

@Tyriar winpty has to change the console font's size to allow for terminals that are especially narrow or wide, because Windows doesn't allow windows narrower than about 140px (assuming ordinary DPI), and it also doesn't allow console windows wider than the display the (hidden) window is on.

Resizing from 159 columns to 160, with a non-CJK code page, I think winpty switches from a size 3x5 Lucida Console font to a size 2x4 font.

I suppose I'll have to reproduce this issue to see what's happening.

[rprichard]

I tried to reproduce the issue by running npm start (after npm install) in the bug repository above, and it worked fine. I also tried catting the test.txt file with WSL bash and Cygwin, and that worked too. I used a VSCode terminal of varying widths above 160 columns.

Maybe the DPI of the monitor is relevant? I only have ordinary DPI displays available, but maybe I can configure a VM somehow.

The winpty-debugserver.exe output might be helpful. (See the https://www.github.com/rprichard/winpty repo for details.)

[Tyriar]

Hmm, I only have a standard dpi monitor too, were you using the default powershell?

[rprichard]

Yes, I'm using the PowerShell default. I was using Win10 v14393, though. Maybe I need a newer version of Windows? I see a v15014 on modern.ie that I could try.

[Tyriar]

@rprichard I was testing on the creator's update too (Windows Insiders).

@bitcrazed I notice the issue you called out above actually says it was tested on 15019 not 14393. So it may be related to Windows Insiders. I did discover that it only happens when the terminal is 160 or more characters in width.

[bitcrazed]

@Tyriar - Apologies, you're right - I mis-read the report.

[Tyriar]

No worries :smiley:

[CaselIT]

@rprichard Yes, it appears to only be broken on windows 10 insiders. I also do not have any problem with the normal version of win10.

[Tyriar]

Sometimes the width may not matter though? https://github.com/Microsoft/vscode/issues/22572

[Tyriar]

Can anyone verify that the workaround that caps the terminal width fixes the issue in the latest Insiders?

[sgtoj]

@Tyriar I cannot confirm if it did fix it, yet. I will confirm that I have this issue on Windows Insider builds. Currently, using 15048 at home and 15055 at work.

[CaselIT]

@tyriar from a quick test it seems that the workaround is working. Thanks!
System details

• VSCode Version: Code - Insiders 1.11.0-insider (6a002910356c6e087dd93e819e4ad54c68b9857a, 2017-03-15T07:11:58.965Z)
• OS Version: Windows_NT ia32 10.0.15055

[rprichard]

I wasn't able to reproduce the issue with 15014, but I can reproduce it with 15048. The underlying winpty console looks fine (e.g. after setting WINPTY_SHOW_CONSOLE=1), which is interesting. I'll keep looking into it.

[rprichard]

This issue appears to be a regression in the Windows console having something to do with its support for single-vs-double-column characters. It doesn't involve colors at all.

It's easy to break ConEmu as well as winpty. Just place this text into a file (and save it UTF-16 LE with BOM):

-２-
-２-
-２-

Then use the type command in PowerShell/CMD, and you'll see the same issue as with winpty/VSCode. Yet, the console buffer looks fine if you press Ctrl-Win-Alt-Space:

The special character here is U+FF12 (FULLWIDTH DIGIT TWO), which is unambiguously a double-column character.

In previous versions of Windows, the ReadConsoleOutput API would return two CHAR_INFO records, both of them with CHAR_INFO.Char.UnicodeChar equal to 0xFF12. The first would have attribute COMMON_LVB_LEADING_BYTE and the second would have COMMON_LVB_TRAILING_BYTE, which allows winpty (and probably ConEmu as well) to recognize that there's only a single U+FF12 character in two cells. Now Windows only returns a single CHAR_INFO record, the the LVB attributes are unset.

I wrote a larger test case here: https://github.com/rprichard/winpty/blob/6360ec6a5bcdc2c16eba7acc3c2d8e72af605407/misc/winbug-15048.cc

I'm not sure I'm going to do anything more on this. I think Microsoft needs to restore the original behavior.

[Tyriar]

@rprichard thanks heaps for looking into this!

@bitcrazed could your team check this out? I've seen this reported quite a bit recently so it's a pretty big impact bug.

[miniksa]

I'm trying to look at this issue this morning.

[miniksa]

@rprichard, I'm looking at your test case there with the 3 examples you gave at the top in https://github.com/rprichard/winpty/blob/6360ec6a5bcdc2c16eba7acc3c2d8e72af605407/misc/winbug-15048.cc

I have commentary for Case 2 & Case 3, but still looking into Case 1.

Case 2: 0x221A takes 1 column usually in Lucida Console unless font is small.

0x221A is an ambiguous width character according to http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt so we base the number of columns on how many pixels wide GDI says that the character is going to render versus the number of pixels wide that a '0' character is. If it starts failing when you use too small of a font, the only solution we have is to use a larger size font or a different font that works for you.

Case 3: 0xFF12 in 'Lucida Console'.

0xFF12 isn't in Lucida Console and the console code hasn't supported font fallback ever, so it displays incorrectly on our window, but shouldn't impact you (I don't think). If you are scraping the contents of our buffer and can do font fallback, you should be able to substitute an appropriate two column character into that space. We want to support font fallback eventually, but it'll just take time.

Case 1: 0x3044 Hiragana I in MS Gothic

I think this is the one that is causing everyone trouble and I'm still looking. Will report back when I figure out what's up. I can reproduce the issue, but now I have to dig in.

[miniksa]

OK, I have Case 1 logged in MSFT:10187355 which is a work item we have been using to greatly expand the test coverage and compatibility with the legacy console for single-byte vs double-byte, single-width vs double-width, Western vs. CJK, Raster font vs TrueType font coverage across ReadConsoleA/W ReadFileA/W ReadConsoleOutputA/W WriteConsoleA/W WriteFileA/W WriteConsoleOutputA/W WriteConsoleOutputCharacterA/W WriteConsoleOutputAttributeA/W and the CRT projections of those (printf, putc, putchar, etc.).

It should be solved when we get that one finished up and out the door.

[rprichard]

@miniksa Thanks for looking at this! Yeah, I may have to stop using such tiny fonts in winpty (e.g. for case 2).

Aside: For determining a character's width in columns, I noticed that the PSReadLine library uses TEXTMETRIC.tmMaxCharWidth rather than the width of the '0' character. My impression was that PSReadLine was replicating the console's internal behavior. Intuitively, comparing against '0' makes more sense.

Aside 2: Out of curiosity, is there a goal of handling code points outside the BMP? The API doesn't seem to allow for it -- a program could write a UTF-16 surrogate pair with WriteConsoleW, but the region I/O functions {Read,Write}ConsoleOutputW expect a single 16-bit value for each buffer cell.

[miniksa]

@rprichard

re: Aside 1:
Well... we were using TEXTMETRIC.tmMaxCharWidth for a while, but it turned out to be unreliable for some fonts. It turns out that text metrics are a mixed bag and sometimes either GDI or the font metadata itself fumbles hard and gives us something really unreasonable when we use that. So I think we're rallying around the size of a '0' until something/someone gives us a better metric. I'm hoping that when we eventually get the time to do DirectWrite that things are sunnier in terms of column measurement in that world than they are in the GDI world, but I don't think I'll know until we try.

re: Aside 2:
There is a goal to handle UTF-16 surrogate pairs. We're working on breaking bad assumptions internal to the console to try to enable full UTF-8 support and full UTF-16 support with surrogate pairs at some point in the future. This issue is a symptom of this work happening internally to prepare for one day having this sort of support.

[Tyriar]

It should be solved when we get that one finished up and out the door.

@miniksa when do you expect the issue to be fixed?

[be5invis]

@rprichard
I've observed that they supported IMEs under no-DBCS codepages, they maybe also changed the layout algorithm that no longer simulates 1980s Hanka (汉卡) behavior that uses two cells to store one character.

ps. I've heard that they are going to make a new CJK typeface and replace the current terminal font (which is in BITMAP!) with it's monospaced version...

[doowonee]

yeah same as me. what are these &nbsp? where are they come from?

• VScode ver: 1.11.2
• OS ver: Windows 10 x64

[miniksa]

There's a known issue. We're trying to figure out what we can do about it. Please be patient. I don't have anything else to share at this time.

[doowonee]

I hope to fix this problem. I'll use external terminal until handle this situation without it VScode is great insofar as I moved from sublime text 3.

[be5invis]

@miniksa Is it because the ReadConsoleOutput no longer duplicate FW characters?
cc. @maximus5

[Tyriar]

This may work as a workaround for PowerShell? From @Roscoe93 in https://github.com/Microsoft/vscode/issues/24737#issuecomment-294126600

temporarily solved by adding this config(when using powershell or cmd as integrated terminal):

"terminal.integrated.shellArgs.windows": [
  "-NoExit",
  "/c",
  "chcp.com 65001"
]

[be5invis]

@Tyriar I think the problem is that...

• In earlier Windows, Console duplicates FW characters under, and only under DBCS CPs and put the duplicated in the ReadConsoleOutput.
• In RS2 they removed duplication but WINPTY is still expecting that...
• In CP65001 there is no duplication (causing FW characters being incorrectly layouted), so changing CP “fixes” this bug.

[rprichard]

I suspect that enabling the legacy console would also work around this issue: https://www.isunshare.com/windows-10/enable-use-legacy-console-for-command-prompt-in-windows-10.html.

[zphhhhh]

I'm using windows 10 Creator version and meet the same problem, is Any way there to solve it ?
VScode version: 1.11.2

[t7yang]

@zphhhhh
as @rprichard reply, enable the legacy console can solve this problem. Confirm here in Windows 10 creator update with VS code 1.11.2.

[eos3tion]

The terminal will be correct when I change my system locale to English(us).
But when I set locale to Chinese(cn),the terminal will broken.

I change "terminal.integrated.shell.windows" to "cmd.exe" "powershell.exe"
the terminal broken.
but "bash.exe" is ok.

My OS is win10 creators update

[rprichard]

There are two separate issues here w/ winpty:

1. ReadConsoleOutput previously represented a double-width character as two CHAR_INFO records using the LVB attributes, and now it only fills one CHAR_INFO record, which breaks the documented 2D-array property of the API's output buffer.
2. Perhaps winpty shouldn't use fonts smaller than some threshold, because they encourage the console to make unreasonable half-vs-full-width decisions.

I'm waiting to hear whether Microsoft can do something about issue 1.

I looked into issue 2 a bit today on Windows v15063. I noticed that WSL Midnight Commander (mc) wasn't laying its text out correctly once mintty->winpty expanded beyond 160 columns, which reduced the font size to 4. The issue was that U+2500 BOX DRAWINGS LIGHT HORIZONTAL was treated as full-width. With a Lucida Console font, it seems to be treated that way at least with sizes 2, 4, 7, and 39. It's also full-width with Consolas at sizes 2, 3, 5, 7, 9, and 24. (I stopped testing after 24.) If the user uses a console with any of those font-size combos, then mc will be broken.

It seems that the console is trying to use the "unpadded" width of a character, so even for characters that are unambiguously half-or-full-width in a particular font, the console sometimes makes the opposite determination. e.g. The "Western" fonts (Lucida Console, Consolas) all think that U+2500 should be half-width--the glyph is half-width, and GetCharWidth32 for U+0030 and U+2500 are equal. Somehow the console decides that it's full-width instead. My current guess is that it's using GetCharABCWidths and noticing that the "B" width is larger than some metric (GetCharWidth32 of "0"?). When U+2500 is full-width, I see that the "C" padding width is -1. Otherwise, U+2500's "A" and "C" paddings are 0.

Some of the CJK fonts treat some of the line-art characters as full-width. (How is a program like mc ever supposed to work portably? Is the Unix situation any better?) When U+2500 is full-width in a font, I think the console always decides, "full width". OTOH, the console will always(?) think U+2502 BOX DRAWINGS LIGHT VERTICAL is half-width, because it's all padding.

It's 10 years old, but this commentary on wcwidth is interesting: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c. It seems like the character widths should be more standardized, but I'm guessing that hasn't happened.

Maybe the console could at least make its character width decision independently of the font size?

[be5invis]

@rprichard Perhaps you are right. Maybe they are comparing against OS/2.xAvgCharWidth.

[rprichard]

@Tyriar I think you disabled the temporary 160 column limit, but in any case, I committed a fix to winpty master tonight ("Stop using fonts smaller than 5px in height") that obsoletes the 160 column workaround. The workaround prevented winpty from reducing the height to 4px, but that won't ever happen with my recent change.

[Tyriar]

@rprichard thanks for letting me know, yes I removed the 160 column workaround as people were still seeing the issue and it impacted other users, particularly those using tmux on Windows.

[Hypnoes]

@eos3tion Because the default encoding of bash is utf-8 and others are not. As someone above have said, while you change the powershell to utf-8 using chcp 65001 , this bug can be fixed manually.

[eos3tion]

@Hypnoes thx,I will try.

[eos3tion]

@Hypnoes
After I typed chcp 65001, the first line is ok,but when i execute cmd,it will broken again like this ↓

[pboymt]

I think it's a bug of Windows Creator Update, not VSCode. All of Terminal software in Windows Creator Update have this problem.

[mysticatea]

• version 1.12.1
• commit f6868fce3eeb16663840eb82123369dec6077a9b
• date 2017-05-04T21:26:50.689Z
• shell 1.6.6
• renderer 56.0.2924.87
• node 7.4.0
• Windows 10 Pro

Full-width characters seem to mess text layout of the integrated terminal. chcp 65001 does not resolve this problem.

[whitecolor]

@Tyriar
Enabling legacy brings other problems. So I still wonder what makes so difficult this bug to be fixed?

[loganmzz]

@pboymt I have the problem only on insider version. See #25126

[Tyriar]

@whitecolor it's an issue in Windows not VS Code, so the difficult part is deploying the fix. I believe it's coming in the next Windows patch.

[StarpTech]

I also run into this issue windows 10 and Vscode 1.12.1

[StarpTech]

@pboymt thx good to know.

[whitecolor]

@Tyriar Well I'm on windows insiders preview, don't see this comming yet.

[Tyriar]

@whitecolor I'm not super clear on the details but it may hit Insiders after or around the same time as Stable.

[louisun]

I find the problem is fixed in Windows 10 Insider Preview 16188.1000.

[whitecolor]

BTW I installed today some updates on windows insiders and it seem that console in VSCode works fine now. maybe it is not because of updates )

[Tyriar]

Woo! 🎉

I'll close this off when I start getting reports of it being fixed in stable Windows.

[fillippeyton]

I'm having the same issue. This is happening to me with Bash in WSL while running multiple NPM commands with Concurrently including Webpack watch, json server, and others. Here's my info:

VSCode Version: 1.12.1 (f6868fc)
Node: 7.4.0
OS Version: Windows 10 Enterprise 64-bit (Version: 1607; OS Build: 14393.1066) (Using WSL for Bash)
Extensions:

Ext | Author | Version |
---------|-----------|------------------
Auto Close Tag | Jun Han | 0.3.12
C# | Microsoft | 1.9.0
Docker | Microsoft | 0.0.13
ESLint | Dirk Baeumer | 1.2.8
npm Intellisense | Christian Kohler | 1.3.0
One Dark Pro | zhuangtongfa | 2.7.0
VSCode Great Icons | Emmanuel Beziat | 2.0.3

[kzhui125]

meet this issue after Windows 10 1703 creators update yesterday..
looks like it will fix in future stable Windows, looking forward to it..

[Kenya-West]

Same here, man. It happens on different sizes of window.

Specs:
Windows 10 Creators Update x64
VS Code up-to-date
bash (Ubuntu on Windows)/Powershell/Whatever

[KostiaChorny]

• VSCode Version: Code 1.12.2 (19222cdc84ce72202478ba1cec5cb557b71163de, 2017-05-10T13:20:36.315Z)
• OS Version: Windows_NT ia32 10.0.15063
• Extensions:

|Extension|Author|Version|
|---|---|---|
|vscode-html-css|ecmel|0.1.4|
|Angular2|johnpapa|2.2.3|
|csharp|ms-vscode|1.9.0|
|bootstrap-3-snippets|wcwhitehead|0.0.9|;

There is the same issue with cmd and PowerShell

[Guema]

i have this kind of messed up layout bug with terminal too. It is unusable at the moment.

[guimou]

Easy to trigger here: one or more backspaces when typing, then return, and you get a "one space" offset. Repeat to add more...
Workaround: cls command resets everything.

[jose-villegas]

I just added a unicode symbol to my PS1 in Bash For Windows (it's the terminal I call from VS), and yeah it seems to be related to that, it adds spaces somewhere.

[Emeryao]

Hi all
I think this issue is gone since KB4020102 has been released which fixes the non-unicode issue for windows10

VS Code terminal now works well on my machine with Windows10 ‪15063.332‬

VS Code Version 1.13.0-insider
Commit 770206ab9c6357943a2145bd3ea49b667f3ff539
Date 2017-05-26T05:14:23.944Z
Shell 1.6.6
Renderer 56.0.2924.87
Node 7.4.0

[AndreiGorlov]

KB4020102 partially fixed issue for me.

Windows 10 RUS:

Windows 10 RUS + ENG lang pack:

Windows 10 RUS + ENG lang pack with cyrillic characters in terminal:

Locale in all cases is ru-RU, only windows gui language is different.

upd:
Version 1.12.2
Commit 19222cdc84ce72202478ba1cec5cb557b71163de
Date 2017-05-10T13:20:36.315Z
Shell 1.6.6
Renderer 56.0.2924.87
Node 7.4.0

[Kenya-West]

@Emeryao @AndreiGorlov when will this update be shipped on Windows 10? I'm afraid to install it manually.
And I check and Settigs app - there's no such update.

UPD: Just go to Settings -> Updates -> Check Updates. It will come immediately. Now works very good.
Windows 10 RUS, VS code 1.12.2
Problem is now solved!

[StarpTech]

yes update KB4020102 also fixed it for me but I couldn't install it at the first time. You have to drive through a real microsoft experience 💃 https://www.drivereasy.com/knowledge/windows-update-error-0x80248007-in-windows-10/

[miniksa]

OK, MSFT:10187355 like I mentioned way up above in this thread transformed into MSFT:11721571 and was packaged as a part of the KB4020102 update yesterday as some of you have already discovered. The fix included in the KB repaired some of the API calls to retrieve console buffer output to match their "Legacy console" or v1 behaviors. Hopefully this resolves some of the issues you all are experiencing.

For a bit of insight as to why this is such an enormously complicated problem and why it took a while to fix, you can check out https://github.com/rprichard/winpty/issues/105#issuecomment-303516064.

[xakep139]

Similar issue that was fixed in Jest: https://github.com/facebook/jest/pull/3626

[leitwolf]

KB4020102 fixed it for me, thanks.

[kidlj]

KB4020102 fixed it for me, thanks +1

[BetaMee]

I have been concerned about this issue for a long time. This afternoon I updated new VS Code Version and I found intergrated terminal is OK . Is this issue fixed by VS Code team or OS update (KB4020102 ) ?
@Tyriar

[Tyriar]

@BetaMee the issue was caused by the Windows Creators Update and fixed in KB4020102 (see https://github.com/Microsoft/vscode/issues/19665#issuecomment-304308207)

[Tyriar]

Reports of this issue have slowed down significantly so I'm assuming that means most people have received the Windows patch and all is well. Thanks @miniksa for handling this :smiley:

If you are still experiencing this issue, please make sure you fully update Windows 10 before reaching out to us.