Skip to content

feat(tui): add debounce logic to escape key interrupt #169

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8 commits into
base: dev
Choose a base branch
from

Conversation

monotykamary
Copy link

@monotykamary monotykamary commented Jun 17, 2025

Summary

• Implements two-stage escape key mechanism to prevent accidental chat operation cancellations
• First escape press shows "esc again interrupt", second press within 2 seconds actually cancels

Screen.Recording.2025-06-17.at.20.24.33.mov

Test plan

  • Start a chat operation that shows "esc interrupt"
  • Press escape once and verify it shows "esc again interrupt"
  • Press escape again within 2 seconds and verify operation cancels
  • Start another operation, press escape once, wait 2+ seconds and verify it reverts to "esc interrupt"
  • Verify normal escape behavior still works for non-busy states

🤖 Generated with opencode

@monotykamary monotykamary force-pushed the feat/escape-key-debounce branch from 0353d53 to a97d81e Compare June 17, 2025 13:55
@adamdotdevin
Copy link
Collaborator

hey, things moved around a little bit, i think we want to move forward with this though; mind updating to work with the dynamic keybinds?

monotykamary and others added 2 commits June 21, 2025 13:28
…dental cancellations

Implements a two-stage escape key mechanism where the first press shows "esc again interrupt"
and requires a second press within 1 second to actually cancel the operation. This prevents
users from accidentally interrupting long-running chat operations while maintaining responsive
cancellation when intentional.

🤖 Generated with [opencode](https://opencode.ai)

Co-Authored-By: opencode <[email protected]>
@monotykamary monotykamary force-pushed the feat/escape-key-debounce branch from 0a1e8e3 to a4ae83a Compare June 21, 2025 06:52
@monotykamary
Copy link
Author

hopefully should be ok

Screen.Recording.2025-06-21.at.13.49.30.mov

@adamdotdevin
Copy link
Collaborator

sorry, i probably wasn't very clear on that last message. we actually have configurable interrupt keybind now, so we can't assume the user with use esc for interrupt. that makes this problem a bit more complex, feel up to tackling it?

@monotykamary
Copy link
Author

ah gotcha, let me have a look

monotykamary and others added 3 commits June 21, 2025 22:38
…tal cancellations

Implements a two-stage interrupt key mechanism that works with any user-configured
interrupt keybind (not just "esc"). The first press shows "esc again interrupt"
and requires a second press within 1 second to actually cancel the operation.
This prevents users from accidentally interrupting long-running chat operations
while maintaining responsive cancellation when intentional.

- Uses dynamic keybind matching instead of hardcoded "esc" key
- Works with leader key sequences and custom interrupt keybinds
- 1 second debounce timeout for optimal user experience
- Real-time UI feedback with hint text updates

🤖 Generated with [opencode](https://opencode.ai)

Co-Authored-By: opencode <[email protected]>
Updates the interrupt hint text to show the user's actual configured interrupt
key instead of hardcoded "esc". Now displays the correct key text for any
configured interrupt keybind (esc, ctrl+c, q, leader+key, etc.).

- Gets interrupt key text from command registry during initialization
- Updates hint display dynamically: "ctrl+c interrupt" → "ctrl+c again interrupt"
- Removes unnecessary fallbacks for cleaner, more confident code
- Handles first render correctly with proper initialization

🤖 Generated with [opencode](https://opencode.ai)

Co-Authored-By: opencode <[email protected]>
@monotykamary
Copy link
Author

hopefully should be ok now
not sure if the placement of the states are tasteful enough, but it shouldn't be too over-engineered in that aspect at least

Instead of storing the interrupt key text, dynamically retrieve it
from the app commands when needed. This reduces state duplication
and ensures the displayed key always matches the configured command.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants