[UncertaintyDeterminesYou4ndMe]

Cause

macOS draws each NSH text into one Core Animation layer, and a layer taller or wider than the GPU's largest texture (16384 pixels) shows nothing. Tool details put a whole Shell output or file in one text, so on a 2x display an output of about 1200 lines showed as an empty box. A single very long line, such as minified JSON, has the same problem across.

Change

CodeText lays its text out in pieces of 200 lines (4000 pt tall at 20 pt lines). Line numbers are padded to one width, so the pieces line up as one column.

A line wider than 800 columns, with East Asian and other wide characters counted as two, is cut and ends with "… N more characters". The copy buttons still copy the whole recorded text.

One trade-off: a text selection cannot cross from one piece into the next. The copy buttons cover copying everything.

AI use

Diagnosis and the patch were done with Claude Code (Claude Opus 5.5). It found the empty box on a local build, matched it to the layer size limit, and wrote the change and its unit test. I checked the fix on a local build with a long Shell output.

[M4n5ter]

English

Please fix the width budget before we merge this. The fixed lineColumns = 800 in codePieces.ts does not cover the supported 130% text size. appearance.ts offers a scale of 1.3, and the AppKit shell applies it to code text too. The truncation suffix also adds width beyond those 800 columns.

Using CoreText with the same NSFont.monospacedSystemFont that NSH uses, at 13 × 1.3 pt on a 2x display:

• 800 ASCII a characters measure approximately 16,715 px wide.
• An input of 830 a characters, cut to 800 plus … 30 more characters, measures approximately 17,154 px wide.

Both exceed the 16,384 px limit this change is intended to avoid, so a supported text-size setting can still reach the dimensions responsible for the empty output. These are native font measurements; I have not reproduced the blank result in a window built from this PR.

Please account for the maximum supported text scale and the suffix in the final width budget, and verify both an exactly-at-limit line and a truncated line at 130% on a 2x display. The 200-line splitting approach otherwise looks reasonable, and the copy path preserves the original text.

简体中文

合并前请先修一下宽度预算。codePieces.ts 固定使用 lineColumns = 800，没有覆盖应用支持的 130% 字号。appearance.ts 提供了 1.3 倍缩放，AppKit shell 也会将它应用到代码文本上。另外，截断后的省略提示还会在这 800 列之外继续增加宽度。

使用 NSH 相同的 NSFont.monospacedSystemFont，通过 CoreText 测量，在 13 × 1.3 pt、2x 屏幕下：

• 800 个 ASCII 字符 a 的实际宽度约为 16,715 px。
• 输入 830 个 a，截成 800 个并追加 … 30 more characters 后，实际宽度约为 17,154 px。

两种都超过了这次改动要避开的 16,384 px 上限，因此使用受支持的字号设置，仍会落入导致输出空白的尺寸范围。这些数据来自原生字体测量；我还没有在基于本 PR 构建的窗口里复现空白结果。

请让最终宽度预算覆盖最大支持字号和省略提示，并在 130% 字号、2x 屏幕下验证“恰好达到列数上限”和“超过上限后被截断”两种输入。其余部分，按 200 行分块的方向可以，复制链路也保留了完整原文。