fix(core): use byte offset for line_starts in text wrap

[zenyr]

Summary

• Fix lineInfo.lineStarts to return byte offsets instead of column offsets
• Prevents character corruption when slicing wrapped multi-byte text (CJK, emoji)

Fixes #609

Changes

• Add byte_offset tracking to VirtualLine and wrap context in text-buffer-view.zig
• Update cached_line_starts to use byte position instead of char/column position
• Add regression tests for CJK text wrapping

Test

buffer.setStyledText(stringToStyledText("흐름도"))
view.setWrapWidth(4)
view.lineInfo.lineStarts // [0, 6] ✅ (was [0, 4] ❌)

---

Design Considerations

Alternatives Considered

Approach	Trade-off
Compute byte offset on-demand at read time	O(n) per lineInfo access — defeats caching purpose
Store only in cached_line_starts without VirtualLine field	Would require extra params in commitVirtualLine, harder to maintain
Derive from chunk byte lengths	Still needs global traversal; chunks are buffer-relative, not document-relative

Chosen approach: Track byte_offset during wrap (O(1) amortized). Memory overhead is ~4 bytes per wrapped line (~80KB for 10K lines), which is acceptable.

Relation to Prior Work

• Initial text truncation + CJK++ word wrap fix #529 (merged): Introduced VirtualLine structure with char_offset. This PR builds on that by adding byte_offset alongside it.
• fix(utf8): use col_offset for CJK word wrap boundary detection #512 (closed): Addressed wrap boundary detection with col_offset in WrapBreak. Different problem — this PR fixes lineStarts return values, not boundary calculation.

Both prior PRs left cached_line_starts using character/column offsets, which corrupts multi-byte characters when used for slicing.

Known Limitation

The no-wrap code path still uses char_offset for lineStarts. This is out of scope for this PR, as wrapping is the primary use case for lineStarts.

---

cc: @DonKongPaPa @kskang @soomtong @stefanahman — you showed interest in #255; this PR addresses a remaining edge case with line boundary handling. Feedback welcome!

[pkg-pr-new]

@opentui/core

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core@610

@opentui/react

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/react@610

@opentui/solid

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/solid@610

@opentui/core-darwin-arm64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-darwin-arm64@610

@opentui/core-darwin-x64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-darwin-x64@610

@opentui/core-linux-arm64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-linux-arm64@610

@opentui/core-linux-x64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-linux-x64@610

@opentui/core-win32-arm64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-win32-arm64@610

@opentui/core-win32-x64

npm i https://pkg.pr.new/anomalyco/opentui/@opentui/core-win32-x64@610

commit: 2823590

[zenyr]

Hi, it looks like the failing test idle() resolves immediately when called on paused renderer might be a flaky timing-based test.

Expected: < 50ms
Actual: 56.31ms

I ran this test locally multiple times and it passed consistently. The changes in this PR only affect text-buffer-view.zig (byte offset tracking), which should be unrelated to the renderer idle logic.

Would it be possible to re-run the CI when you have a moment? Please let me know if there's anything else I should address. Thank you!

[zenyr]

Update from Discord discussion:

Addressed the "Known Limitation" mentioned in the PR body—no-wrap mode now uses byte_offset too.

Also optimized hot paths based on feedback about avoiding repeated measure calls:

Commit	Change
00336eb	Fix no-wrap to use byte_offset (was still using char_offset)
089f334	Refactor to proactive tracking—no more retrospective getBytes() loop
e344f44	Add byte_start/byte_len to VirtualChunk—eliminates findWrapPosByWidth recalculation during word-wrap reflow

The bigger refactor (merging findGraphemeInfo/findWrapBreaks into a single loop) is worth a separate issue.

Future optimization: unified grapheme/wrap-break loop

Currently findGraphemeInfo and findWrapBreaks in utf8.zig iterate over text separately:

• findGraphemeInfo → collects byte_offset, byte_len, width, col_offset
• findWrapBreaks → collects byte_offset, char_offset (no width info)

Both use similar SIMD-accelerated loops with ASCII fast paths. Merging them would:

1. Single pass instead of two
2. WrapBreak gets byte_len/width → word-wrap can use cached breaks directly
3. Eliminates grapheme lookups in hot path entirely

This could make grapheme_start in VirtualChunk redundant (replaced by byte_start), and remove the need for charOffsetToColumn conversions during wrap.

Estimated ~250 LOC across 4 files.

[simonklee]

I think you still need to recompute the byte window to match the new column slice. Otherwise when the prefix ends mid‑chunk, byte_len still equals the full chunk length.