Conversation
Several views (YAML/JSON detail, selector, multi-selector, confirm) accepted both Esc and q to go back/cancel, while only Esc was shown in the hints. Because q is also the application quit key in the list view, this dual meaning was both inconsistent and risky: muscle memory built up on q-to-go-back could quit the whole app unexpectedly. Make Esc the single, uniform "back / cancel / close" key everywhere, and reserve q exclusively for quitting the application from the list view: - Detail view: remove q-to-go-back; Esc returns to the list. - Selector / multi-selector / confirm dialogs: remove q as a cancel key; Esc cancels (n/N still answer "No" in the confirm dialog). - Help overlay: Esc (or ?) now closes it, and the overlay captures input so list actions no longer fire behind it. Ctrl+C still quits anywhere. - Add an "[Esc] cancel" hint to the confirm dialog for consistency, and update the help footer and README to reflect Esc as the back key. Add regression tests asserting q no longer cancels the dialogs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JdFBtn5iLbiaZ4Tc693pVz
Removing q as a back key exposed a latent bug: the detail view (YAML/JSON, describe, logs, and the "Delete Result" / "Rollout Restart" screens) could become impossible to leave with Esc. Two causes: 1. Esc in the detail view only cleared an active search query on the first press instead of exiting, so a confirmed search made Esc appear dead (the old q handler exited unconditionally, masking this). Esc now returns to the list in a single press; an *open* search bar is still closed first by the IsSearching() branch. 2. detail.SetContent did not reset search state, so a leftover query or open search bar from a previous view leaked into the next one (e.g. the reused detail model behind "Delete Result") and absorbed every key, stranding the user. SetContent now clears all search state. Also reset the stuck loading flag when showing the delete/rollout result. Add regression tests covering single-press Esc exit and search-state reset; all three fail against the previous code. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JdFBtn5iLbiaZ4Tc693pVz
My previous change removed q as a back key to make Esc the single uniform exit. That regressed badly: in terminals and multiplexers where a lone Esc is delayed or swallowed (e.g. tmux's default escape-time), Esc is unreliable in TUIs — which is exactly why the original report was "the hint says Esc but the real key is q". Removing q left result windows (e.g. "Delete Result") with no working exit at all. Key point: in the detail/result views and dialogs, q never quit the application — it only goes back/cancels. It quits *only* from the list view. So keeping q there is safe and gives a reliable exit alongside Esc. - Detail/result views: Esc and q both return to the list in one press. - Confirm / selector / copy dialogs: Esc and q both cancel. - Help overlay: Esc, q or ? closes it (q does not quit while it is open). - List view: q / Ctrl+C still quit (unchanged). Esc reliability fixes from the previous commit are kept: SetContent resets search state so a stale query/open search bar can't absorb Esc, and the delete/rollout result paths clear the stuck loading flag. Update hints (now "[Esc/q]") and tests accordingly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JdFBtn5iLbiaZ4Tc693pVz
Lowercase q and Esc now always mean "go back / cancel" and never close the application. Only capital Q (the configurable quit key, default "Q") and Ctrl+C quit telekube. This removes the risk of a stray q killing the app while keeping q/Esc as reliable, safe back keys — including in terminals where a lone Esc is delayed (e.g. tmux). - Default keybinding quit changed from "q" to "Q". - List view: Q / Ctrl+C quit; lowercase q does nothing. - Detail/result views: Esc / q go back, Q / Ctrl+C quit. - Help overlay: Esc / q / ? close it; Q / Ctrl+C quit. - The list-view and help quit paths use the configured quit key. Made it explicit in the UI and docs: - Footer now shows "[Q]uit" (uses the configured key). - Detail header shows "[Q]uit" alongside "[Esc/q] Back". - Help overlay distinguishes "Esc / q Go back (never quits)" from "Q / Ctrl+C Quit the application". - README gains a callout explaining back vs quit, updated shortcut tables, and the config example now shows quit: "Q". Tests updated: Q quits from list and detail, lowercase q does not quit. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JdFBtn5iLbiaZ4Tc693pVz
…n-0m22f9 # Conflicts: # internal/tui/app_test.go
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
2 participants
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.
Summary
This PR standardizes keyboard navigation across the TUI by establishing Esc as the uniform "cancel/back" key across all dialogs and views, while reserving 'q' exclusively for quitting the application from the list view. This prevents accidental application termination when users press 'q' out of muscle memory while in dialogs.
Key Changes
ConfirmModel,SelectorModel, andMultiSelectorModel. Now only Esc cancels dialogs.ConfirmModel,SelectorModel, andMultiSelectorModelImplementation Details
The key insight is that dialogs should not respond to 'q' since it's reserved for application-level quit functionality. This prevents users from accidentally quitting the app when they meant to cancel a dialog. The help overlay now has explicit input handling that closes on Esc or '?', ensuring consistent behavior across the application.
https://claude.ai/code/session_01JdFBtn5iLbiaZ4Tc693pVz