Skip to content

[Feature]: Async terminal response handling to surface transmission errors #12

Description

@hisanari-dev

Motivation

blit always sets q=2 (suppress all kitty protocol responses) because it does not read stdin asynchronously to parse protocol responses — reading them would risk leaking response bytes into Neovim's normal input stream if not handled carefully. The consequence, documented in docs/spec/kitty-graphics.md's "Response handling" section, is that blit cannot currently detect terminal-side transmission errors (e.g. a malformed PNG rejected by the terminal); failures are only visible if they cause a visible rendering problem, with no error surfaced through :checkhealth or a return value.

Proposed Solution

Add an async stdin reader that recognizes and consumes kitty graphics protocol response sequences specifically (leaving all other input untouched) and surfaces any error responses through blit's existing nil, err_msg return-value pattern where still possible, or through :checkhealth blit for errors that occur outside a synchronous call (e.g. during a debounced redraw). This is nontrivial: it needs to coexist safely with Neovim's own input handling and must not misinterpret unrelated terminal input as a graphics-protocol response.

Alternatives Considered

  • Status quo (q=2, no response handling): simple and safe (zero risk of corrupting Neovim's input stream), and transmission failures are rare in practice for well-formed PNGs — this is why it was accepted for v0.x rather than treated as a blocking gap.

Additional Context

Explicitly called out in docs/spec/kitty-graphics.md as "a future-version consideration, not implemented speculatively" — this issue exists so that consideration doesn't get lost, not because a concrete failure has been observed yet.

Checklist

  • I have searched existing issues to make sure this is not a duplicate.
  • I have described the problem and the proposed solution clearly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions