Change:
} //#endregion <ins> /** * Computes the offset after performing a left delete on the given string, * while considering unicode grapheme/emoji rules. */ export function getLeftDeleteOffset(offset: number, str: string): number { if (offset === 0) { return 0; } // Try to delete emoji part. const emojiOffset = getOffsetBeforeLastEmojiComponent(offset, str); if (emojiOffset !== undefined) { return emojiOffset; } // Otherwise, just skip a single code point. const codePoint = getPrevCodePoint(str, offset); offset -= getUTF16Length(codePoint); return offset; } function getOffsetBeforeLastEmojiComponent(offset: number, str: string): number | undefined { // See https://www.unicode.org/reports/tr51/tr51-14.html#EBNF_and_Regex for the // structure of emojis. let codePoint = getPrevCodePoint(str, offset); offset -= getUTF16Length(codePoint); // Skip modifiers while ((isEmojiModifier(codePoint) || codePoint === CodePoint.emojiVariantSelector || codePoint === CodePoint.enclosingKeyCap)) { if (offset === 0) { // Cannot skip modifier, no preceding emoji base. return undefined; } codePoint = getPrevCodePoint(str, offset); offset -= getUTF16Length(codePoint); } // Expect base emoji if (!isEmojiImprecise(codePoint)) { // Unexpected code point, not a valid emoji. return undefined; } if (offset >= 0) { // Skip optional ZWJ code points that combine multiple emojis. // In theory, we should check if that ZWJ actually combines multiple emojis // to prevent deleting ZWJs in situations we didn't account for. const optionalZwjCodePoint = getPrevCodePoint(str, offset); if (optionalZwjCodePoint === CodePoint.zwj) { offset -= getUTF16Length(optionalZwjCodePoint); } } return offset; } function getUTF16Length(codePoint: number) { return codePoint >= Constants.UNICODE_SUPPLEMENTARY_PLANE_BEGIN ? 2 : 1; } function isEmojiModifier(codePoint: number): boolean { return 0x1F3FB <= codePoint && codePoint <= 0x1F3FF; } const enum CodePoint { zwj = 0x200D, /** * Variation Selector-16 (VS16) */ emojiVariantSelector = 0xFE0F, /** * Combining Enclosing Keycap */ enclosingKeyCap = 0x20E3, } </ins>

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: All recent versions, maybe all versions, including Monaco outside of VSCode OS Version: macOS, Windows, likely Linux and all others Steps to Reproduce: an Emoji with a modifier, such as a Fitzpatrick skin type modifier: backspace after that character to the Unicode specification the entire character should be removed. removes the modifier and leaves the Emoji, producing The relevant spec, , states that: This is probably related to , directly to , but separate enough that I suppose it warrants its own issue. It's worth noting that aspects of this work as expected. The editor won't let you select he modifier - it correctly forces you to select the modifier plus the Emoji it modifies as an atomic whole. As reported in though it's possible to move the cursor inside the modified grapheme cluster and break it. (While the cursor bug doesn't appear in the Monaco playground the backspace bug does). <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Since about 6 months, we have implemented Unicode's grapheme break rules. So it is not possible to place the cursor inside emojis. A Delete (Fn+Backspace) before the emoji will remove the entire grapheme. But Backspace will only delete one code point at a time. We have made the decision to behave like this due to it being used for input building in various languages. See example in . See also There's also an interesting blog post at
Thanks for explaining - I guess that means there's a disagreement with the Unicode spec? Needing to hit backspace seven times to delete a single flag, for example, is something the spec was trying to prevent. The example in seems like a different issue, especially since the spec calls out Emoji, Emoji with modifiers, and Emoji Tag Sequences as specific and separate things. I guess I'm a little confused if you are more or less explaining the context behind why this bug exists or saying that the VSCode team doesn't plan on fixing it or that y'all disagree that it's a bug.

In any case thanks for your help. I know text editing is hard - that's why I've been excited to try out Monaco because it seems like it does a better job than most web-based components.
There's no disagreement with the Unicode spec. In our code, we currently lack the ability to distinguish the emoji flag case from the Thai characters case. Since this use case is important for typing in Thai, we have chosen to allow backspace to remove the last code point from a grapheme, regardless of which grapheme that is. We would need to further refine this and make backspace delete the entire grapheme in case the grapheme is an emoji.
is there a way we can reclassify this as a bug report vs. a feature request since it's actually reporting a failure to handle Unicode text properly? It's totally understandable that fixing this could involve a lot of work and only cure relatively rare cases of text; but those are still legitimate cases. Maybe it's just me but I'd feel much better if it were closed at rather than a feature request that didn't garner enough support. That is, okay we close this bug report and call it a feature request but unless Monaco starts distinguishing Emoji characters from others it will continue to be a bug in Monaco whether it's on the roadmap or not. seems more honest or less dismissive. Thanks again for interacting here. We've continued to incorporate more of the Monaco APIs into Simplenote and while some things are still a bit unsteady it's been a nice improvement for the most basic text editing functionality.
Another use-case is for
Interestingly, even browsers show different behaviors when hitting backspace after Emojis with modifiers or combinations of those separated by the Zero Width Joiner (ZWJ).

Firefox 88: Address-bar: "" -"" Address-bar: "‍‍‍" -"‍‍" -"‍" -"" -"" Input/Text-Areas behave the same Chrome 90: Address-bar: "" -"" -"" Input/Text-Area: "" -"" Address-bar: "‍‍‍" -"‍‍‍" -"‍‍" -"‍‍" -"‍" -"‍" -"" -"" Input/Text-Area: "‍‍‍" -"" Monacos behavior seems to be consistent with Chromes address-bar. I think Firefox got it right: It always removes the modifier with the modified emoji, but deletes ZWJ-combined emojis step by step. You can even combine modified Emojis (‍‍‍)! VS Codes html input fields behave as Chromes input fields. Thus, combined emojis are deleted at once. What should be implemented for Monaco?