fix(tui): yank cell/row no longer reports "No row selected"

[TimelordUK]

The bug

Filter down to a single row (f + a term), navigate to a cell, press yv — the status bar says "No row selected" and nothing is copied. Reported from real use: pulling version numbers out of a TeamCity CSV, cell by cell.

Root cause

Yank resolves its row from Buffer::get_selected_row() (src/handlers/yank.rs:43), which was backed by ratatui's TableState — a second source of truth for the crosshair, separate from the ViewportManager / view_state.crosshair_row position the table actually renders.

Only two things ever wrote it:

• row navigation — sync_row_state() (src/ui/traits/navigation.rs:37), i.e. j/k/G
• query execution — reset_table_state() → reset_navigation_state()

Loading a file does neither: new_with_dataview and add_dataview_with_refs install the DataView and the ViewportManager but never initialise the selection. So it stayed None until you moved the cursor — and on a view narrowed to one row, j/k can never fire. Hence "consistent with a single row in the view".

The two filter halves had also drifted apart:

path	key	resets selection?
apply_fuzzy_filter_with_refs	Shift+F	yes — set_selected_row(Some(0)) + vm.set_crosshair_row(0)
apply_text_filter_with_refs	f	no — applied the filter, set a status message, nothing else

Second bug, same root

No clamping either. Navigate to row 57, then filter down to one row: the selection stayed at Some(57), dataview.get_cell_value(57, col) returned None, and yank silently copied the string NULL.

The fix

get_selected_row() derives from the crosshair. It now reads view_state.crosshair_row, returns None only when there are genuinely no visible rows, and clamps to the view's row count. Kills both failure modes. TableState is untouched and still drives rendering; the only functional caller of get_selected_row() was yank (the rest are debug dumps and one unwrap_or(0)).

The f text filter resets to the first match, mirroring the fuzzy filter — viewport ref threaded in from enhanced_tui::apply_filter. Better behaviour in its own right, independent of the yank bug.

Tests

New tests/test_yank_single_row_repro.rs — fresh load has a selection, empty results don't, both filters keep a selection at a single row, and the selection is clamped so yank reads the visible cell.

Two existing tests asserted the old contract using buffers with no data at all (test_buffer::test_buffer_navigation, test_buffer_state_refactor::test_direct_buffer_viewstate_access); they now install data, since an empty buffer having no selection is correct under the new semantics.

• cargo test — 688 + 412 + 1 passed, 0 failed
• cargo fmt / cargo clippy — clean, no new warnings
• Python suite — 497 passed; the 18 failures are the known Windows-local .exe-suffix noise, green in CI
• Examples — all FORMAL passed, only pre-existing smoke failures

Verified by hand against the original CSV that triggered the report.

Follow-up, not in this PR

f is the text filter and Shift+F the fuzzy filter per KeyMapper (src/ui/key_handling/mapper.rs:222), but src/config/key_bindings.rs:365 and dispatcher.rs carry the opposite mapping. They're dead duplicate tables that KeyMapper overrides — worth pruning so the code and the help agree.

🤖 Generated with Claude Code