Commit Graph

2 Commits

Author SHA1 Message Date
Levi Neuwirth aa3cd4da34
fix(editor): the renderer never got the mode everything else was reading
The frame resolved ui.line-wrap, recorded it on the window, and fed it
to the coordinate mapping and the scroll indicator --- while the
viewport handed TextView::render a hard-coded Truncate. With the
default of wrap, that meant the cursor was placed for wrapped text and
the indicator reckoned against wrapped rows while the text was still
clipped at the edge. The worst possible split: every part that reports
where things are agreed, and the part that draws them did not.

The viewport now reads window.last_wrap, so it consumes the same single
resolution as everything else rather than resolving again.

How it survived: the edit was in a script that raised on a LATER
assertion, so nothing was written; a follow-up script's replace then
matched nothing and silently did nothing. Every test I had asked "is
the mode right?" and none asked "is the text wrapped?", so all of them
passed.

Hence the new witness reads the GRID. the_default_actually_wraps_the_
painted_text goes through RenderState and reconstructs rows from the
emitted CellDelta spans, for two reasons: the defect lived in the
DRIVER, between the resolved mode and the viewport it built, so a test
building its own viewport would have passed against it --- and the
spans are what a TUI actually consumes. truncate_clips_the_painted_text
is its control, so the pair is discriminating rather than merely true.

It bites: restoring the hard-coded Truncate fails the wrap witness
while all five other tests keep passing, which is exactly the shape
that let it through.

Gates: fmt, workspace clippy -D warnings, diff --check, --lib 1917/0,
crdt 2102/0, line_wrap 6/6, tab_width 2/0, folding 21/0,
full_grid_resync 1/1.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
2026-08-07 18:48:11 +02:00
Levi Neuwirth 4a26f0005e
fix(linewrap): the toggle wrote the global layer, not the buffer
ui.line-wrap is buffer-local, and the toggle was built from
pmacs.config.get(name) and pmacs.config.set(name, value) --- both of
which address the GLOBAL layer. The registry's buffer-local surface is
get(name, buf) and set_local(buf, name, value), and the command used
neither.

The result was wrong in both directions at once, which is why it needed
two witnesses rather than one. In a buffer pinned to truncate, the
toggle would read "wrap" from the global layer, decide the next mode is
truncate, and leave that buffer exactly as it was --- while writing
truncate globally and flipping every buffer that had no override of its
own. The command that changes nothing here and everything elsewhere.

Now resolves the buffer ONCE and uses it for both calls. Once matters:
resolving twice would be a narrower version of the same bug, since the
active buffer can change between two calls.

Two witnesses in a new acceptance suite, and both bite against the code
review rejected --- restoring the global-layer toggle fails both while
the default and enum tests keep passing, which is exactly how it
shipped. the_toggle_moves_this_buffer_and_leaves_the_other_alone covers
the leak outward: a second buffer and the global layer must be
untouched. a_pinned_buffer_toggles_from_its_own_value covers the miss
inward: a buffer whose value differs from global must toggle from ITS
value.

Note on the second buffer: there is no Lua buffer-switch, so "the
other" is a buffer that exists but is not shown. That is the case that
matters anyway --- a global write reaches every buffer without an
override, shown or not.

Gates: fmt, workspace clippy -D warnings, diff --check, --lib 1916/0,
line_wrap_acceptance 4/4.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
2026-08-07 18:22:40 +02:00