Change:
return allWidthsComputed; } <ins> private _checkMonospaceFontAssumptions(): void { // Problems with monospace assumptions are more apparent for longer lines, // as small rounding errors start to sum up, so we will select the longest // line for a closer inspection let longestLineNumber = -1; let longestWidth = -1; const rendStartLineNumber = this._visibleLines.getStartLineNumber(); const rendEndLineNumber = this._visibleLines.getEndLineNumber(); for (let lineNumber = rendStartLineNumber; lineNumber <= rendEndLineNumber; lineNumber++) { const visibleLine = this._visibleLines.getVisibleLine(lineNumber); if (visibleLine.needsMonospaceFontCheck()) { const lineWidth = visibleLine.getWidth(); if (lineWidth > longestWidth) { longestWidth = lineWidth; longestLineNumber = lineNumber; } } } if (longestLineNumber === -1) { return; } if (!this._visibleLines.getVisibleLine(longestLineNumber).monospaceAssumptionsAreValid()) { for (let lineNumber = rendStartLineNumber; lineNumber <= rendEndLineNumber; lineNumber++) { const visibleLine = this._visibleLines.getVisibleLine(lineNumber); visibleLine.onMonospaceAssumptionsInvalidated(); } } } </ins> public prepareRender(): void { throw new Error('Not supported'); }

Discussion:
Issue Type: <bBug</bOpen a new blank file and paste this: Then start typing after "starthere", in the same line. On my system, the cursor runs ahead of the text being typed. See the gif: ! Tried it on fresh install of the latest insider's edition, without extensions. VS Code version: Code - Insiders 1.38.0-insider (, 2019-08-19T12:53:09.586Z) OS version: Linux x64 4.9.0-9-amd64, XFCE on Debian 9.9 <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
Are you using any form of zoom? Or a high DPI monitor? Is the cursor drawn correctly when setting ?
related -
I am not using zoom, I was able to repro it on stock insiders edition, without any additional settings. It's a 2K monitor. I can't repro the issue on my home HD monitor, so that might be it. I will post more info tomorrow, when I get back to work, where the monitor is.
I just remembered I was supposed to post more info here :). seems to solve the issue, but VSCode freezes after about a minute of playing around with this setting, and has to be killed by the system. My feeling is that some miscalculation happens after typing for awhile. With , the editor freezes. Without, the incorrect character measurement is introduced, which exhibits like shown above. My display settings are on the screenshot. ! The bug is reproducible on either monitor.
Some more experimenting. It seems it doesn't matter which character I type.Everything seems fine at first, I can type multiple lines of characters without issues. But then I click around a bit, play with selection and then it happens. Afterwards, I can type anywhere, and characters will be incorrectly measured.If I open a new tab, and start typing, everything is fine in that tab (so the incorrect measurement is tied to a tab)I said above that causes editor to freeze. But now I managed to make it freeze without this setting at all, just by holding a single character for a while. Not sure if this is a separate issue or related (EDIT: I suspect freezing is related to the measurement issue).

I've installed version 1.28.2, which is the one my colleague uses successfully on a similar system. Both the freezing and misaligned cursor disappeared. So the problem was introduced within the last 1 year.
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command pallete to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Given we're not likely to get a response within the next few hours, do you know any way to verify?
I'll be able to try it out tomorrow.
I haven't been able to reproduce this myself, so the change was optimistic to begin with. Since nothing is broken, adding .
I just VNC-d to work computer and tested it. I was able to repro the bug again on the old stable version, and couldn't repro it on the latest insiders. So it seems to be fixed! :+1:

Issue Type: <bBug</bI can't figure out the exact repro steps, but I've had this happen several times, starting immediately after I updated from the last version of vscode: The cursor gets drawn one character before the actual location. For example, in a typescript file I click past the end of the line, but the cursor gets drawn before the ; at the end of the line. However if I start typing the new text is after the semicolon. Closing the file and re-opening it seems to fix it for a while, but the problem eventually comes back. This is the first time I've seen this in VS Code, although I've seen a similar issue in Monaco before. When we see it there the cursor is usually offset less than an entire character, so it get's drawn on top of the character preceding the cursor location VS Code version: Code 1.36.1 (, 2019-07-08T22:55:08.091Z) OS version: Linux x64 4.19.34--g5b63d4390e96 <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ lit-html1.11.0 soysyntaxchecker3.24.2 bazel-code0.1.9 prettier-vscode1.9.0 nearley1.0.3 vscode-docker0.7.0 Go0.11.4 vscode-typescript-tslint-plugin1.2.2 team1.149.2 vscode-template-literal-editor0.9.0 show-offset0.0.4 java0.47.0 vscodeintellicode1.1.8 vscode-java-debug0.20.0 clang-format1.9.0 vscode-proto30.3.0 </details<!-- generated by issue reporter --
I just had this happen again. It seemed like as I kept typing the cursor was being drawn further and further away from the actual location. Also the error underlines were also drawn before the word that should have been underlined by the same amount as the cursor.
Version 1.36.1 turned out to be unusable for me because of this. I moved back to 1.35.1 and the problem went away.
can you reproduce this issue when disabling all extensions?
Yes, this screenshot is from a session with all extensions disabled: !

Same issue here (Version 1.36 as well as 1.36.1, Debian Stretch environment on Google Chrome OS). Also the height of a line seems to be increasing by a tiny bit the moment that line is changed the first time. This issue is rendering VS Code unusable for me, so I ended up rolling back to 1.35.1, where the issue does not exist.
cc as it only occurs from 1.36
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
This issue is not fixed and I gave the requested info immediately when it was requested.
can you try our exploration builds and check if the issue still persists . Thanks!
Does this reproduce only with certain fonts? What linux distribution are you using? Does this reproduce only on certain (longer) lines? Are you using zooming? () Are you on a high DPI monitor? I need to be able to reproduce on my machine in order to figure out what's wrong, but in the meantime you could use: in your settings to workaround.
I'm having the exact same issue! I was just about to create a new issue but I guess I'll tack onto this one instead. I'm also running Debian Stretch and have had this weird font issue since upgrading to 1.36 (and 1.36.1). I am unable to reproduce it in 1.35.1 after downgrading to it. Having extensions enabled or disabled does not make a difference. It happens sometimes when I create a new line and start typing. The font will look different from the other lines and the cursor will get more and more displaced depending on how much text is in the line. I'm unable to provide the exact steps to reproduce as it seems random but it happens pretty often. When switching to another tab then back again the font gets corrected. I'll provide a couple of images. See the bottom "Lorem ipsum" looking different from the comment above. ! Here's a long line showing the cursor displacement: ! After switching tab and going back: !
This flag seems to fix the cursor displacement for me, but sometimes the font still gets weird for me (which gets fixed when switching tab back and forth). Could it be 2 separate issues at play?

I'm using debian stretch under Crostini on a Google Pixelbook. It does have a high resolution display, and I've been running with the "high density" option turned on for vs code. My font family is set to 'Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback' and the font size is 16 pixels. It does seem to get worse the more I type on the line. If I move the cursor to a line that hasn't been modified it seems to display correctly. I tried going back to low density for vs code, I'm still seeing the same problem and sometimes it also draws the cursor too far to the right instead of the left: ! does seem to fix the problem I've also seen this happen in Monaco on chrome with it's default fonts, although it happens much less often there. I tried downloading the linked exploration build with electron 6, but it says the blob doesn't exist. Is there a more up to date version?
Are you certain you have disabled all extensions and have never ever messed with the CSS shipped with VS Code? I'm asking because we would render in exactly the same way an edited line, or a line that is currently being edited, like a line which was never edited... so having decorations rendered correctly after switching tabs and going back is IMHO quite weird. This is scary, why would the font change? Are you perhaps using IME and doing composition? Thanks for following through and confirming that the monospace optimizations are to be blamed in your case... Unfortunately, I will need to set up Debian Stretch to try and reproduce... Conceptually, here is what we are doing: on startup we render 1000 s, 1000 s, 1000 s, etc and we establish if the font is monospace by reading their widths. If all widths are equal, we will consider the font monospace and we'll store the charWidth. if we think the font is monospace, we render decorations in the editor a lot faster, by using simple multiplication (decoration at character i should be painted at offset i * charWidth, etc.)

It looks that for you, we detect the font as being monospace at startup, but then it actually isn't... Perhaps under your OS the font is lazy loaded or some other bizarre thing where the initial measurements are no longer correct... But I'm speculating, as I didn't really reproduce...
I have also observed that switching tabs temporarily fixes it, with all extensions disabled. But then it comes back as I start editing the file. Everything renders correctly when the file is loaded, it's only after editing things that the cursor starts to drift away.
I'm not sure if it's relevant, but I just wanted to point out that I'm using debian stretch on Chrome OS, which uses Wayland/Sommelier instead of X. Could there be some difference in font metrics because of wayland?
I'm sure it happens without extensions, I just tried it again. And I have not messed with any CSS. I tried but the issue remains. I'm not using an IME. One weird thing I just noticed was when I did a search all, the font changed for each result/item I hovered over, as if getting corrected. It kinda feels like there are two fonts battling... I would've suspected my PC was messed up somehow if it didn't go away every time I downgrade to 1.35. When I upgraded back to 1.36.1 I noticed the font for the release notes looked off, which I recognized from (the font is correct in 1.35). !
Could you please attempt the following: install a free font like Hack or Fira Mono configure I'm trying to understand if this has something to do with our default linux fontFamily, where we use multiple fonts for fallback purposes.
Well, that made the error manifest itself a bit differently.. with the old font family my cursor always got pushed to the right, now it's in the middle of letters when editor.disableMonospaceOptimizations is off: ! With it on it gets like this: ! Like I also have a high DPI display by the way, perhaps that's related?
I want to point out that I'm not using ChromeOS and I have the issue.. I have noticed some font oddities in Chrome as well though. Could this be some chromium wide thing? Was there a chromium/electron upgrade between 1.35 and 1.36?

Yes, 1.36 was the first version of VS Code to ship with Electron 4.
I have this issue too, since 1.36 on ChromeOS. The only extensions I have are Rewrap and Vim. I haven't changed the VS Code CSS. My laptop has a HiDPI display, but I'm using VS Code on a standard-DPI external display. Disabling monospace optimizations fixes the issue for me. Random lines get the cursor drawn to the right of the insert/edit location, and in Vim normal mode I can see the blinking cursor shows the under-cursor character when blinking (at the wrong position), but shows the line's true content when not blinking. Incorrect line content while blinking: ! True line content: ! Here, we can see the cursor pushed waaaay over from the end of the line. The bug seems to get worse the longer the line is. !
I've personally not seen this issue for quite a while. Maybe it was another electron update that fixed it, but that's just a guess.
I have a fresh Crostini install on a fresh Powerwash Chrome OS (beta channel) today and I'm seeing this issue (also my laptop is locking up as I'm working in VSCode, maybe related?)
Same problem with 1.41.1 on Windows. The offset gets worse the further the cursor moves to the right.
Anyone who has seen this, can you verify that it is fixed in VS Code Insiders? Or do you have repro steps?
I was never able to repro, but since nothing is broken I will optimistically add to this.