Skip to content

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

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

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

Conversation

@unagi
Copy link

@unagi unagi commented Feb 13, 2026 •
edited
Loading

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)

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
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.
@german-one
Copy link
Contributor

german-one commented Feb 15, 2026

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
arrow_terminal_ps75

PS 5.1
arrow_terminal_ps51

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
fix(host): align conpty default text measurement with ambiguous width…
4a09610 
… policy

Reason: when --textMeasurement is omitted, conpty init could leave width recognition mode implicit, causing ambiguity-width related drift.

Scope: always initialize VtIo text measurement to graphemes by default and add regression tests for default/explicit textMeasurement+ambiguousWidth propagation.

Breaking changes: none.
@unagi unagi force-pushed the dev/ray/ambiguous-width-narrow-wide branch from 82d9bad to 4a09610 Compare February 17, 2026 06:08
@unagi
Copy link
Author

unagi commented Feb 17, 2026 •
edited
Loading

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

image image

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.

4 participants

@unagi @lhecker @german-one @DHowett