REP corrupts some Unicode characters (emoji) #20283

Closed
opened 2026-01-31 07:09:03 +00:00 by claunia · 2 comments
Owner

Originally created by @dgl on GitHub (Jul 24, 2023).

Windows Terminal version

1.18.1462.0

Windows build number

10.0.25300.1000

Other Software

No response

Steps to reproduce

Repeating some emoji with an escape sequence results in mojibake. In WSL or any Linux:

$ printf '\e[6n💓\e[1b\e[6n\n';cat
💓�
^[[4;1R^[[4;4R^C

Expected Behavior

On a recent xterm (run with xterm -fa Mono -fs 14, to get TrueType fonts) the output is:

$ printf '\e[6n💓\e[1b\e[6n\n';cat
💓💓
^[[4;1R^[[4;5R^C

Windows Terminal also behaves as expected for , this only affects some emoji characters.

Actual Behavior

As above, the second character is corrupted, see screenshot too.

image
Originally created by @dgl on GitHub (Jul 24, 2023). ### Windows Terminal version 1.18.1462.0 ### Windows build number 10.0.25300.1000 ### Other Software _No response_ ### Steps to reproduce Repeating some emoji with an escape sequence results in mojibake. In WSL or any Linux: ```console $ printf '\e[6n💓\e[1b\e[6n\n';cat 💓� ^[[4;1R^[[4;4R^C ``` ### Expected Behavior On a recent xterm (run with `xterm -fa Mono -fs 14`, to get TrueType fonts) the output is: ```console $ printf '\e[6n💓\e[1b\e[6n\n';cat 💓💓 ^[[4;1R^[[4;5R^C ``` Windows Terminal also behaves as expected for ✅, this only affects some emoji characters. ### Actual Behavior As above, the second character is corrupted, see screenshot too. <img width="550" alt="image" src="https://github.com/microsoft/terminal/assets/5385/bd4a08a3-8d1a-4d2f-806f-30546633342d">
claunia added the Issue-BugResolution-Duplicate labels 2026-01-31 07:09:03 +00:00
Author
Owner

@lhecker commented on GitHub (Jul 24, 2023):

Hey! This issue is a duplicate of #15390. 🙂 I believe #15541 made it possible to fix the issue for this particular escape sequence. I'm not entirely sure which part in our code base doesn't handle surrogate pairs, etc., but I suspect it can be discovered by setting a breakpoint on AdeptDispatch::_FillRect.

/dup #15390

@lhecker commented on GitHub (Jul 24, 2023): Hey! This issue is a duplicate of #15390. 🙂 I believe #15541 made it possible to fix the issue for this particular escape sequence. I'm not entirely sure which part in our code base doesn't handle surrogate pairs, etc., but I suspect it can be discovered by setting a breakpoint on `AdeptDispatch::_FillRect`. /dup #15390
Author
Owner

@microsoft-github-policy-service[bot] commented on GitHub (Jul 24, 2023):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@microsoft-github-policy-service[bot] commented on GitHub (Jul 24, 2023): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#20283