Keep the cockpit's place, and stop $EDITOR taking it down - #1
Merged
Conversation
QA of every footer binding, driven through Textual's test pilot and a real pty for the one key headless cannot reach. Rebuilding the findings table dropped the cursor to row 0 and re-fired RowHighlighted, so marking or refreshing from any row but the first threw the user back to the top of the list, swapped the detail pane, and discarded the code leads they had just traced. The old test only ever marked the first row, where a reset to row 0 is indistinguishable from no reset at all. The selection is now captured before the rebuild and put back after it, with a guard so the transient row-0 highlight is not mistaken for a move the user made. A filter matching nothing left selected_key pointing at a finding that was no longer on screen, so f/t/m/R acted on it — including filing a retest for a finding the user could not see. An empty result now selects nothing, and the action keys say so rather than going quiet. $EDITOR is a command line, not a program name: EDITOR="code -w" looked for a program called "code -w" and the FileNotFoundError propagated out of the action and killed the session over a typo in an env var. It is split now, and an editor that will not start — or a terminal that cannot suspend — is reported in the status bar. Retests bounce with "Finding not found" wherever the server's retest.request takes a bare finding_id: ids repeat across stores, so an engagement finding is looked up among manual pentest findings and misses. The finding is fine, the request could not name it. Say that, instead of a message that reads as though it had been deleted. Also: the counts line tracks the filter, so "22 findings" no longer sits above three visible rows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
QA of every footer binding, driven through Textual's test pilot and a real pty for the one key headless cannot reach.
Rebuilding the findings table dropped the cursor to row 0 and re-fired RowHighlighted, so marking or refreshing from any row but the first threw the user back to the top of the list, swapped the detail pane, and discarded the code leads they had just traced. The old test only ever marked the first row, where a reset to row 0 is indistinguishable from no reset at all. The selection is now captured before the rebuild and put back after it, with a guard so the transient row-0 highlight is not mistaken for a move the user made.
A filter matching nothing left selected_key pointing at a finding that was no longer on screen, so f/t/m/R acted on it — including filing a retest for a finding the user could not see. An empty result now selects nothing, and the action keys say so rather than going quiet.
$EDITOR is a command line, not a program name: EDITOR="code -w" looked for a program called "code -w" and the FileNotFoundError propagated out of the action and killed the session over a typo in an env var. It is split now, and an editor that will not start — or a terminal that cannot suspend — is reported in the status bar.
Retests bounce with "Finding not found" wherever the server's retest.request takes a bare finding_id: ids repeat across stores, so an engagement finding is looked up among manual pentest findings and misses. The finding is fine, the request could not name it. Say that, instead of a message that reads as though it had been deleted.
Also: the counts line tracks the filter, so "22 findings" no longer sits above three visible rows.