Skip to content

Add configurable ambiguous-width policy (narrow/wide)#19864

Open
unagi wants to merge 2 commits intomicrosoft:mainfrom
unagi:dev/ray/ambiguous-width-narrow-wide
Open

Add configurable ambiguous-width policy (narrow/wide)#19864
unagi wants to merge 2 commits intomicrosoft:mainfrom
unagi:dev/ray/ambiguous-width-narrow-wide

Conversation

@unagi
Copy link

@unagi unagi commented Feb 13, 2026

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

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)

@unagi
Add configurable ambiguous-width policy (narrow/wide)
8c80a61 
Reason:\n- Address ambiguous-width rendering requests discussed in microsoft#153 and microsoft#370 without introducing a locale-based default policy.\n\nScope:\n- Add compatibility.ambiguousWidth as narrow|wide and wire it through settings model/schema/UI.\n- Propagate the selected mode through Terminal -> ConPTY -> winconpty -> conhost argument paths.\n- Replace fixed ambiguous width handling in CodepointWidthDetector with policy-based resolution and keep related width paths consistent.\n- Extend regression coverage for ambiguous symbols, DEC special-character alignment, fallback lifecycle stability, and emoji/VS16-adjacent behavior.\n\nBreaking changes:\n- None. Default behavior remains narrow.
@unagi
Copy link
Author

unagi commented Feb 13, 2026

@microsoft-github-policy-service agree

@lhecker
Copy link
Member

lhecker commented Feb 13, 2026 •
edited
Loading

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:

image

@lhecker lhecker added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Feb 13, 2026
@unagi
Copy link
Author

unagi commented Feb 14, 2026

@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.

image

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.

image

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.

image

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

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Feb 14, 2026
@unagi
chore: remove newline-only noise in ambiguous-width changes
9016630 
Reason: review pointed out unnecessary newline code changes in PR microsoft#19864.

Impact: keep logical changes intact while normalizing edited files to repository line endings.

Breaking change: none.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@DHowett DHowett DHowett left review comments

@lhecker lhecker lhecker left review comments

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

Needs-Attention The core contributors need to come back around and look at this ASAP.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@unagi @lhecker @DHowett