PSReadLine
PSReadLine copied to clipboard
Using an emoji as the prompt text parse error replacement causes glitchy text to remain in the text buffer
Prerequisites
- [X] Write a descriptive title.
- [X] Make sure you are able to repro it on the latest released version
- [X] 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
- Write text containing a character that will cause PSReadline to register a parsing error, such as
hello world( - Press
Escto 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.
I think this relates to my issue https://github.com/PowerShell/PowerShell/issues/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.
@totkeks thank you for your work!