This seems to be in line with the emoji-sequences table in the latest
version of the Unicode standard: those glyphs require U+FE0F to activate
their emoji presentation. Since we don't support composing U+FE0F, we
should not present them as emoji by default.

Fixes #5910.

Yes, I hate this.

(cherry picked from commit c39f9c6)

This removes all glyphs from the emoji list that do not default to
"emoji presentation" (EPres). It removes all local overrides, but retain
the comments about the emoji we left out that are Microsoft-specific.

This brings us fully in line with the most popular Terminals on OS X,
except that we squash our emoji down to fit in one cell and they let
them hang over the edges and damage other characters. Oh well.

Refs #900, #5914.

This removes all glyphs from the emoji list that do not default to
"emoji presentation" (EPres). It removes all local overrides, but retains
the comments about the emoji we left out that are Microsoft-specific.

This brings us fully in line with the most popular Terminals on OS X,
except that we squash our emoji down to fit in one cell and they let
them hang over the edges and damage other characters. Oh well.

## Detailed Description of the Pull Request / Additional comments

Late Friday evening, I tested my emoji test file on iTerm2. In so doing, I realized
that @j4james and @leonMSFT were right the entire time in #5914: Emoji
that require `U+FE0F` must not be double-width by default.

I finally banged up a powershell script that parses the UCD and emits a codepoint
width table. Once checked in, this will be definitive.

Refs #900, #5914.
Fixes #5941.

This removes all glyphs from the emoji list that do not default to
"emoji presentation" (EPres). It removes all local overrides, but retains
the comments about the emoji we left out that are Microsoft-specific.

This brings us fully in line with the most popular Terminals on OS X,
except that we squash our emoji down to fit in one cell and they let
them hang over the edges and damage other characters. Oh well.

## Detailed Description of the Pull Request / Additional comments

Late Friday evening, I tested my emoji test file on iTerm2. In so doing, I realized
that @j4james and @leonMSFT were right the entire time in #5914: Emoji
that require `U+FE0F` must not be double-width by default.

I finally banged up a powershell script that parses the UCD and emits a codepoint
width table. Once checked in, this will be definitive.

Refs #900, #5914.
Fixes #5941.

(cherry picked from commit ba1a298)

…t#5914)

This seems to be in line with the emoji-sequences table in the latest
version of the Unicode standard: those glyphs require U+FE0F to activate
their emoji presentation. Since we don't support composing U+FE0F, we
should not present them as emoji by default.

Fixes microsoft#5910.

Yes, I hate this.

This removes all glyphs from the emoji list that do not default to
"emoji presentation" (EPres). It removes all local overrides, but retains
the comments about the emoji we left out that are Microsoft-specific.

This brings us fully in line with the most popular Terminals on OS X,
except that we squash our emoji down to fit in one cell and they let
them hang over the edges and damage other characters. Oh well.

## Detailed Description of the Pull Request / Additional comments

Late Friday evening, I tested my emoji test file on iTerm2. In so doing, I realized
that @j4james and @leonMSFT were right the entire time in microsoft#5914: Emoji
that require `U+FE0F` must not be double-width by default.

I finally banged up a powershell script that parses the UCD and emits a codepoint
width table. Once checked in, this will be definitive.

Refs microsoft#900, microsoft#5914.
Fixes microsoft#5941.

This PR introduces `compatibility.ambiguousWidth` as a **global**
compatibility setting (`narrow` default, `wide` optional).

The default remains `narrow`.

Why global-only in this PR:
- Width detection is currently process-wide (`CodepointWidthDetector`
  singleton).
- True profile-level ambiguous-width behavior would require broader
  architectural changes and is intentionally deferred to a follow-up
  design/PR.

What this PR guarantees:
- Terminal-side handling is consistent end-to-end for the selected
  ambiguous-width policy (rendering path + ConPTY/host propagation).

Known limitation:
- Some client applications (for example PSReadLine/readline-based apps)
  may still compute character widths independently.
- In such cases, cursor movement or Backspace behavior can differ from
  visual cell width even when terminal-side policy is consistent.

This is a compatibility/readability trade-off feature:
- `narrow`: prioritize cross-application compatibility.
- `wide`: prioritize readability with many CJK fonts.

Closes #153
Closes #370
Refs #2928
Refs #2049, #2066, #2375, #900, #5910, #5914

Co-authored-by: Leonard Hecker <[email protected]>