OhMyPosh agnoster theme causes command to snap back on typing third character

[hchokshi]

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Windows 10 18362.30 (Enterprise)
  oh-my-posh 2.0.263 - agnoster theme
  posh-git 0.7.3
  Screenshots taken using Nerd Fonts Inconsolata NF, also tried using FuraCode NF with same results.
  I am using a build from master as of ~11am PDT today.

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
  Windows Terminal
  
  Fluent Terminal (expected result)
  
  Windows Terminal (oh-my-posh disabled, posh-git enabled)
  

Windows Terminal with agnoster - the problematic theme

In this case, I typed test then backspaced the 4 characters and typed cd. The e from test is still rendered in its original position, while the other characters erased as expected.

Typing tes, the te is rendered in its original position and moved position:

Typing further works as expected, removing those characters from the screen:

• What's wrong / what should be happening instead:
  Typing the third character should not cause the command to move its rendering (see cd ~ and Get-Command in first screenshot - first character gets covered, no issues with one or two character commands.

There is no theme with ohmyposh disabled (poshgit still enabled), or with different ohmyposh themes including the others that render those arrows. Only agnoster causes this moving to occur.

[zadjii-msft]

This seems like we've got the width of the glyphs wrong. Conpty thinks the cursor advanced by one, but we're trying to render it in two cells, or vice-versa.

I coulda swore @miniksa had a fix for this somewhere...

[miniksa]

I didn't have a fix for this, just several internal reports of the same issue in different circumstances. I'll dig in when I get time.

[ksiazkowicz]

The easiest way to reproduce that is probably putting this in your PowerShell profile.

function prompt {
    return '✔ ';
}

Just pasting the text in quotes into Terminal makes it buggy.

[DHowett-MSFT]

This is actually, weirdly, the same issue as #633. You wouldn't expect it, but they're two sides of the same coin.

The powerline glyphs are in a region of the character table specified as "ambiguous width." Whenever we get one of those, we ask the font how wide the grapheme cluster is. This is required to eventually support things like Devanagari and other N:M glyph->cell mapping scripts. Anyway, the standard NerdFont patcher installs the powerline glyphs as double-width glyphs.

So, Windows Terminal asks how wide the powerline characters are and gets "two cells".

There's a conhost instance backing every tab. That one also (for a long list of legacy compatibility reasons that are better explained in #1739) needs to count cells and widths and characters and stuff. That one is not using the same font, so it gets a different answer: "one cell".

They trivially and immediately disagree on where the cursor is, and where all characters after the mis-identified grapheme cluster are.