Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
3 tasks done
matteocoder opened this issue Nov 3, 2023 · 2 comments · May be fixed by #4462
Open
3 tasks done
Labels
In-PR A PR is opened targeting the issue Needs-Triage 🔍 It's a new issue that core contributor team needs to triage.

Comments

@matteocoder
Copy link

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

glitchy buffer
glitchy buffer2

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.

@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage 🔍 It's a new issue that core contributor team needs to triage. label Nov 3, 2023
@totkeks
Copy link

totkeks commented Feb 7, 2025

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.

Image

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 totkeks linked a pull request Feb 7, 2025 that will close this issue
5 tasks
@microsoft-github-policy-service microsoft-github-policy-service bot added the In-PR A PR is opened targeting the issue label Feb 7, 2025
@matteocoder
Copy link
Author

@totkeks thank you for your work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
In-PR A PR is opened targeting the issue Needs-Triage 🔍 It's a new issue that core contributor team needs to triage.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants