[GH-ISSUE #1464] [Bug] Terminal line restoration guide ignores normalization and Unicode widths #496

New issue

Closed

opened 2026-10-15 18:25:35 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:25:35 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 10, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1464

The rendered-line guide introduced by #1450 says padding a trimmed line to frame.columns restores the fixed-width row, and describes serialized_state as exact terminal state. The producer normalizes both lines and serialized state; terminal cell width is not a normalized JavaScript string length.

Independent reproduction with pinned Linux Node 24.18.0, real public CLI/MCP PTY capture, a 55-byte source-owned Node target and an 80-column terminal:

Without normalization, the old first line is ID plus 78 spaces (80 characters); the compact first line is ID, and padding to 80 recovers the old line.
With the selected literal replacement ID → LONG_IDENTIFIER, the old normalized first line has 93 characters; the compact line has 15. Padding the latter to 80 gives 80 characters, not the prior 93. The original admitted PTY chunks and normalized serialized content are retained; owned cleanup and MCP text/structured parity/ping pass.
A second production TerminalRenderer control uses combining e\u0301 with 20 columns and identity normalization. The old row has 21 UTF-16 code units; the trimmed row has 2. Padding to 20 again does not restore the prior string.

This is a documentation/representation-description bug, not evidence that the compact format lost original PTY chunks. Clarify that columns records terminal cells, lines are normalized text with trailing U+0020 removed, and serialized_state has the selected normalization applied. Explain where admitted original PTY chunks remain available. Do not promise universal restoration by padding to columns.

Searched public issues for rendered-line normalization/padding; #724, #1250, #61 and #57 are related but do not track this incorrect restoration recipe. Refs #1450, #1065, #723.

Originally created by @N0zoM1z0 on GitHub (Oct 10, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1464 The rendered-line guide introduced by #1450 says padding a trimmed line to `frame.columns` restores the fixed-width row, and describes `serialized_state` as exact terminal state. The producer normalizes both lines and serialized state; terminal cell width is not a normalized JavaScript string length. Independent reproduction with pinned Linux Node 24.18.0, real public CLI/MCP PTY capture, a 55-byte source-owned Node target and an 80-column terminal: - Without normalization, the old first line is `ID` plus 78 spaces (80 characters); the compact first line is `ID`, and padding to 80 recovers the old line. - With the selected literal replacement `ID` → `LONG_IDENTIFIER`, the old normalized first line has 93 characters; the compact line has 15. Padding the latter to 80 gives 80 characters, not the prior 93. The original admitted PTY chunks and normalized serialized content are retained; owned cleanup and MCP text/structured parity/ping pass. - A second production TerminalRenderer control uses combining `e\u0301` with 20 columns and identity normalization. The old row has 21 UTF-16 code units; the trimmed row has 2. Padding to 20 again does not restore the prior string. This is a documentation/representation-description bug, not evidence that the compact format lost original PTY chunks. Clarify that `columns` records terminal cells, `lines` are normalized text with trailing U+0020 removed, and `serialized_state` has the selected normalization applied. Explain where admitted original PTY chunks remain available. Do not promise universal restoration by padding to `columns`. Searched public issues for rendered-line normalization/padding; #724, #1250, #61 and #57 are related but do not track this incorrect restoration recipe. Refs #1450, #1065, #723.

bsakaguchi

2026-10-15 18:25:35 +00:00