Closed
Conversation
Terminals using the Kitty keyboard protocol (Ghostty, Kitty, WezTerm) send Ctrl+C and ESC as escape sequences rather than raw signals. The existing stdin reading (fmt.Scanln, bufio.ReadString) blocked waiting for a newline and never processed these, leaving users stuck. Add internal/prompt package that reads stdin in raw terminal mode, handling Ctrl+C (0x03) and standalone ESC (0x1b) as cancel. Arrow keys and other escape sequences are detected via a 50ms lookahead and discarded rather than triggering cancel. Multi-byte UTF-8 input is consumed cleanly. Falls back to buffered line reading when stdin is piped (tests). Replace all 9 fmt.Scanln/bufio.ReadString call sites in cmd/root.go and internal/mob/init.go with the new prompt.ReadLine/Confirm functions.
- pickMob: handle ErrCancelled with "Cancelled." message instead of propagating as an error. main.go exits cleanly (code 0) on ErrCancelled. - ESC detection: 50ms lookahead distinguishes standalone ESC from arrow key / escape sequences. Added comment about orphaned goroutine safety. - Remove unused fd parameter from isStandaloneEsc and drainSequence. - UTF-8 multi-byte input: emit terminal bell on discard so the user gets feedback that the character was rejected.
drainSequence had a race with the goroutine in isStandaloneEsc: the goroutine closed the channel after sending one byte, so drainSequence could see a closed channel and return before consuming the full sequence, leaking terminator bytes (e.g. arrow up leaked 'A'). Fix: goroutine only reads the first byte after ESC; drainSequence reads remaining bytes directly from stdin. readLineFallback created a new bufio.Reader per call, so its internal buffer swallowed all remaining piped input on the first read. Chained ReadLine calls (e.g. setupRepo prompts) got EOF on the second and third call. Fix: use a package-level reader initialized lazily on first use.
The goroutine-based ESC sequence detection and UTF-8 continuation byte handling were overengineered for short prompts (mob names, y/n). Revert to treating any 0x1b byte as cancel - arrow keys also cancel, which is fine for the inputs we accept. Non-ASCII bytes are silently ignored by the default case.
Member
Author
|
im unsure about this one, i think i was trying to optimize some ghostty bug |
Member
Author
|
this issue is almost certainly fixed by #24 |
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.
No description provided.