Using an emoji as the prompt text parse error replacement causes glitchy text to remain in the text buffer

[matteocoder]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues, especially the pinned issues.

Exception report

N/A

Screenshot

Environment data

PS Version: 7.4.0-rc.1
PS HostName: ConsoleHost (Windows Terminal)
PSReadLine Version: 2.3.4
PSReadLine EditMode: Windows
OS: 10.0.22621.1 (WinBuild.160101.0800)
BufferWidth: 78
BufferHeight: 43

Steps to reproduce

Prerequisite: use the following profile.ps1

if (([console]::outputEncoding).EncodingName -ne 'Unicode (UTF-8)') {
    #[Console]::InputEncoding = [Console]::OutputEncoding = $OutputEncoding = [System.Text.Utf8Encoding]::new()
}
function prompt {
    "👉 "
}
Set-PSReadLineOption -PromptText '👉 ','❌ '
Set-PSReadLineOption -predictionsource none

1. Write text containing a character that will cause PSReadline to register a parsing error, such as hello world(
2. Press Esc to delete the whole line

Expected behavior

The text buffer should be completely cleared.

Actual behavior

The characters which caused the parse error remain stuck on the buffer, and cannot be accessed by moving the cursor to their position. Additionally, when the parse error happens, the error prompt shifts slightly to the right.

[totkeks]

I think this relates to my issue PowerShell/PowerShell#21363

When you use a glyph there that uses more than one byte, like your icons do or my icons in the issue, then the calculation of those are wrong.

The function LengthInBufferCells on https://github.com/PowerShell/PSReadLine/blob/master/PSReadLine/Render.Helper.cs#L49 returns that these icons use two cells in the buffer, when they are actually just using one, even if rendered as two when using a proportional font like Cascadia Code Nerd Font variant.

The function returns 4 for my '╰󰅚 ' prompt, which is unicode f015a or \udb80\udd5a, while you can see it uses only 3 buffer cells.

I don't know what a surrogate pair is, but it seems it doesn't work properly with that:

// We can ignore these ranges because .Net strings use surrogate pairs
// for this range and we do not handle surrogate pairs.

[matteocoder]

@totkeks thank you for your work!