support variation selectors, ZWJ sequences and surrogate pairs in length calculation

[fabsenet]

Fixes #1847

• I have read the Contribution Guidelines
• I have checked that there isn't already another pull request that solves the above issue
• All newly added code is adequately covered by tests
• All existing tests are still running without errors

AI

I am working with unicode, windows-1252 and codepages as part of my day job for quite some time. I used Claude Code here as a tool to write faster. I checked every little change myself.

Changes

src/Spectre.Console/Internal/Cell.cs

• GetCellLength(string): NET6+ → delegates to UnicodeCalculator.GetWidth(string) which already handles grapheme clusters correctly via EnumerateRunes(); netstandard2.0 → iterates with StringInfo.GetTextElementEnumerator
• GetCellLength(ReadOnlySpan<char>): now delegates to the string path instead of iterating char-by-char
• New private GetClusterCellLength(string): FE0F → 2, ZWJ → 2, surrogate pair → code point width lookup

src/Spectre.Console/Rendering/Segment.cs

• Split(): char-foreach replaced with StringInfo enumerator — prevents splits in the middle of a grapheme cluster
• Truncate(): same change
• SplitSegment(): same change

src/Spectre.Console.Tests/Unit/CellTests.cs (new)

• 8 parameterized tests: ASCII, CJK, ♥, ❤️, ZWJ family sequence, ❤️‍🔥, flag 🇩🇪, empty string

src/Spectre.Console.Tests/Unit/Widgets/Table/TableTests.cs

• New snapshot test Should_Render_Table_With_Wide_Emoji_Correctly

---

Please upvote 👍 this pull request if you are interested in it.

[fabsenet]

@microsoft-github-policy-service agree

[fabsenet]

you have to look at the expected output in the terminal as also vs code or github tend to render it incorrectly!

[patriksvensson]

Sorry, but I have a bit difficulty understanding these changes. I appreciate the PR but all logic for Unicode calculation should go into the wcwidth library.

Why use UnicodeCalculator on net6 and above and a complete different approach otherwise?

[fabsenet]

the problem is the length counting in char by char.
the wide heart basically has two unicode chars "heart + wide" but the original logic was counting them one by one and "wide" on its own has a width of zero. So the original logic has 1+0=1. but the actual printed char takes the space of 2 normal characters and thats why the table is drawn wrong.

the easy fix would have been to fix the one-by-one counting to detect the "wide" and change the result but it would have been a single fix only. this approach now fixes more cases.

[patriksvensson]

The string overload in UnicodeCalculator does this already afaik.

[patriksvensson]

I appreciate it, but I would rather get the calculation correct in wcwidth to be honest since it's used by other projects as well (the reason for it existing).

I'll take a look at this PR as soon as I can.

[fabsenet]

this obviosly is now not fixed for .net standard 2.0. UnicodeCalculator.GetWidth(string) is not available for .net standard?

[patriksvensson]

You are completely correct. I look forward to drop netstandard2.0 at some point (around the 2.0 release of Spectre.Console). For now, I'm OK with having two different implementations (and potentially erroneous rendering on .NET Framework). What do you think?

[fabsenet]

i reworked it to use the UnicodeCalculator.getstring more, this makes it a bit easier now!

[patriksvensson]

Ok, I've looked through it, and I think I understand the changes now. Will take it for a spin after I've merged another emoji-related bug tonight.

[patriksvensson]

I think this looks good. No tests are failing and it solves the issue. Some minor nit-pick thing that needs to be fixed though.

[fabsenet]

Hi i am not sure what to do right now. i am fine with the change of extra brackets but i do not see an accept button anywhere? do i need to put this change in my branch? i see no simple accept button anywhere?

[patriksvensson]

I already took care of it 🙂

[patriksvensson]

Merged! Thank you for your contribution. Much appreciated! 👍