Add configurable ambiguous-width policy (narrow/wide)

[unagi]

Summary of the Pull Request

Add a configurable compatibility.ambiguousWidth setting and allow ambiguous-width behavior to be explicitly selected as narrow or wide.

The default remains narrow.

References and Relevant Issues

• Related: Add an option to toggle the width of ambiguous-width characters #153
• Related: Ambiguous width character in CJK environment #370
• Background: TermControl: force all ambiguous glyphs to be narrow #2928
• Context: Some DEC Special Graphics characters aren't quite right #2049, Consider making ConPTY and Windows Terminal treat all ambiguous-width characters as 1 cell instead of asking the font #2066, Crash: Use after free of std::function through CodepointWidthDetector #2375, Certain "emoji" are still half-sized #900, Emoji character width / spacing too large (Black Medium Square) #5910, CodepointWidthDetector: reclassify U+25FB, U+25FC as Narrow #5914

Detailed Description of the Pull Request / Additional comments

Background (#2928)

We understand the rationale in #2928 for favoring fixed/predictable behavior for ambiguous width handling.
This PR keeps that principle by preserving narrow as the default, while adding an explicit opt-in path for users who need wide.

What this PR changes

• Settings:
  • Add compatibility.ambiguousWidth with narrow|wide (no locale mode)
• Wiring:
  • Propagate the setting through WT -> ConPTY -> winconpty -> conhost argument paths
• Core behavior:
  • Replace fixed ambiguous-width handling in CodepointWidthDetector with policy-based resolution (narrow=1, wide=2)
  • Apply the policy consistently through affected width-calculation paths
• Regression coverage:
  • Add/update tests around DEC special characters, ambiguous symbols, fallback lifecycle stability, and emoji/VS16-adjacent behavior

Compatibility

• No breaking changes.
• Default behavior remains narrow.

Localization note

This PR adds new Settings UI strings in en-US only.
Localized resources will be handled in the subsequent Localization Updates flow after this PR is accepted.

Validation Steps Performed

• Verified staged changes with git diff --check
• Verified no remaining locale-mode wiring or constants for ambiguous width
• Reviewed diffs across settings/schema/UI, ConPTY wiring, core width logic, and tests

PR Checklist

• Closes #xxx
• Tests added/passed
• Documentation updated
  • If checked, please file a pull request on our docs repo and link it here: #xxx
• Schema updated (if necessary)

Scope Clarification (added after review feedback)

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

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.

[unagi]

@microsoft-github-policy-service agree

[lhecker]

Can you please post a screenshot of your build showing how it works with the ambiguous width character "…"?

If you're on the latest Windows version, testing it is very easy: Simply run edit.exe and open the "File" context menu. It should look like this, but with a wide "…" character:

[unagi]

@lhecker

As requested, here are screenshots showing the behavior before and after my change.

Settings UI

This shows the new ambiguous width option in the compatibility settings.

After fix (Ambiguous width = Wide)

The arrow character (→, EastAsianWidth=Ambiguous) is measured as two cells.
The cursor position, spacing, and following characters are aligned correctly.

Before / Narrow mode

With the current default behavior (Ambiguous treated as narrow),
the same character is measured as one cell while the glyph visually occupies
almost two cells in typical CJK fonts.
This causes the next character to overlap and the cursor position to drift.

This demonstrates that allowing an explicit ambiguous-width policy
improves layout correctness in CJK environments without changing the default behavior.

[german-one]

Fonts may have an influence. Perhaps this is the reason why you are facing overlapping glyphs, which I was not even able to reproduce (FWIW, Cascadia Mono in my case).

Besides of that, my observation is that PowerShell 5.1 in particular bahaves weirdly. As your screenshots seem to demonstrate how it looks like in PS 5.1 only, I'm wondering what this setting does to the experience in other shells?

I tried to have the cursor visible in the screen captures, just to show that the "A" is written adjacent to the last arrow, no matter if the cursor has been already advanced to an even farther position in PS 5.1.

PS 7.5

PS 5.1

Other shells (CMD, WSL) do not misplace the cursor. The behavior of PS 5.1 can also be reproduced in a conhost window though.

To be clear, I'm not questioning this new setting. And I also don't know how much my observations interact with specifics of CJK scripts in general. However, it might be more reasonable to make it a profile setting

• if the appearance differs depending on the shell used
• if it may cause misalignments in text mode interfaces like in the menu of @lhecker's screenshot or in apps like Far Manager

What do you think?

[unagi]

@german-one
Thank you for the feedback. Let me add the context and intent.

In real CJK usage, some users choose fonts that render East Asian Ambiguous characters as width 2 for readability. This PR provides wide as a relief option for that kind of environment. At the same time, the default remains narrow, so compatibility-first behavior is preserved by default (wide is explicit opt-in).

We also recognize the side effect that cursor/Backspace behavior can diverge in readline-based environments. That behavior depends on how the receiving application computes character width. We are not hiding this; it is now explicitly documented as a known limitation in both the HelpText and the PR description.

So the intent of this PR is to provide an explicit option for readability-focused cases, while clearly disclosing the tradeoff.

I also attached reference screenshots (HelpText reinforcement in Settings, plus the known readline-side behavior).

[BlueRain-debug]

@german-one Thank you for the feedback. Let me add the context and intent.

In real CJK usage, some users choose fonts that render East Asian Ambiguous characters as width 2 for readability. This PR provides wide as a relief option for that kind of environment. At the same time, the default remains narrow, so compatibility-first behavior is preserved by default (wide is explicit opt-in).

We also recognize the side effect that cursor/Backspace behavior can diverge in readline-based environments. That behavior depends on how the receiving application computes character width. We are not hiding this; it is now explicitly documented as a known limitation in both the HelpText and the PR description.

So the intent of this PR is to provide an explicit option for readability-focused cases, while clearly disclosing the tradeoff.

I also attached reference screenshots (HelpText reinforcement in Settings, plus the known readline-side behavior).

I think it would be better to add a third option (auto?) to automatically determine the width based on the current font (similar to Conhost's behavior)? ofc I admit that implementing this might involve some work.

[DHowett]

I think it would be better to add a third option (auto?)

We are absolutely not going to do that. That was one of the biggest mistakes the original Windows Console made, and it means that standards-conforming applications cannot accurately predict how big something is going to be without knowing--and manually parsing--the font. Accessing the font is impossible over a remote connection (for example, and among other reasons.)

If you want that behavior, you can stick with the original Windows Console. 🙂

[unagi]

Thanks everyone for the feedback and discussion.

I agree that an automatic/font-dependent mode is probably not the right direction, since it can make character width less predictable for applications (especially over remote connections).

What this PR is trying to do is more limited: keep today’s default behavior as-is, while offering an explicit opt-in for users/environments (including some CJK setups) that prefer ambiguous characters to be treated as wide.

So the intent here is explicit selection with clear tradeoffs (narrow / wide), rather than adding an auto mode.

[j4james]

FYI, there is a mode supported by some terminals to switch between narrow and wide for ambiguous width characters. That at least allows applications to make the choice to opt in if they're prepared to handle the non-standard widths.

That said, you may still want the option to allow users to force the mode on, and I'm in agreement with @german-one that it should probably be a per-profile setting. I understand that there may be architectural reasons why this isn't feasible.

ETA: The mode number I'm referring to is ?8428. When set, ambiguous width is narrow; when reset, it's wide. The only terminals I'm aware of that support this are MLTerm and RLogin.