help palette: the wheel moves the cursor too, and a gate that meant it (C41) - #160
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #158, from the design-supervisor audit C41 shipped without. Three findings, all fixed here; no rollback, nothing user-visible regressed.
D1 — the wheel scrolled past the row
↵runs (high)C41's contract is C27's verbatim: the view follows the cursor; the cursor does not follow the view. The keyboard path branched on
filtering(app.rs); the wheel arm never got the same branch and kept callinghelp_scrollunconditionally. With the filter open, three notches puttop=29undercursor=0— the overlay pointing at a row off screen, one↵from running it. Exactly the failure the clause forbids, and the roster's own wheel eight lines above does the right thing.One notch = one command now, the arrow keys' step. Un-filtered the wheel still reads C15's poster on by the page.
Gated by
the_wheel_moves_the_palette_cursor_rather_than_scrolling_past_it, mutation-checked: reverting the branch fails it (cursor: left 0, right 3).D2 — the width gate passed by construction (med)
the_palette_cursor_marks_a_row_without_costing_it_a_columnclosed onassert_eq!(help_layout(body, &km, Some(q)).content, unmarked)— buthelp_layouttakes no cursor, so that compared one pure call to an identical earlier one. Changing&prefix[1..]to&prefix[..](the marker taking a column of its own — the precise thing the gate names) left it passing.It now reads the claim off the drawn buffer: the marked row, with the glyph put back to the space it spent, must be byte-identical to the same row drawn unmarked. Mutation-checked — that edit now fails it on a one-column shift.
The property itself always held; only the gate was empty. The audit filed this as the ninth instance of DESIGN-ui.md §"On gates that pass by construction".
D3 — C39's wording table went stale (med)
C41 relabelled the filtering hints (
read on→move,↑↓ more→↑↓ move, added↵ run/↵ runs) without amending the table that documents them. Table updated to match the code, with a paragraph on why the wording changed. The two un-filtered rows are untouched.Also
❯its "third overlay"; it is the fourth — C20's feed uses it too.§ C41gains The wheel is a motion key too, and the mark-spends-no-width clause now describes the gate that actually measures it.Verification
cargo test: 993 unit (+1) and all 36 suites green, 0 failures.cargo fmtclean;cargo +1.96.1 clippy --all-targets -- -D warningsclean.Not fixed, deliberately
Two uncontracted gaps the audit logged, neither reachable on the default keymap: motion keys are fully inert when a query matches rows but no commands, and
topis not re-followed on resize. Both want a contract before code.