Inline Image Protocols (Partial Support)
iTerm2 images have a path; Sixel and Kitty are not complete in stable.
Availability
Partially implemented in stable. Read the limits below before relying on this workflow.
Reviewed against stable v0.5.1. Rust candidate additions are labeled separately. Release status.
The pain this solves
- Charts and previews can help in terminal workflows.
- Image protocols need separate decoding, placement, and rendering support.
What ships with it
- Stable source has an iTerm2 OSC 1337 image handler and rendering path.
- Sixel and Kitty sequences are intercepted by a bridge.
- Stable code marks Sixel decoders and Kitty state management as future work.
Questions this answers
- Which inline image path is implemented in stable?
- Are Sixel and Kitty image decoding complete?
- Does stable preserve every image through scrollback?
How it works
The stable Swift source contains an iTerm2 OSC 1337 image handler and image extraction/rendering path. This supports a bounded iTerm2 image claim, not every image format or placement behavior.
The Rust bridge can enable or intercept iTerm2, Sixel, and Kitty protocol sequences. In the rendering path, Sixel and Kitty handling is explicitly marked as future work for decoders and state management.
Stable Chau7 should not advertise complete Sixel or Kitty display, universal scrollback image retention, or broad format support. Those behaviors require complete decode, placement, rendering, and persistence paths.
Why it matters
Inline images can help with charts and previews, but protocols have distinct decoding and placement requirements. The stable description should name the implemented path and the incomplete ones.
Frequently asked questions
Which inline image path is present in stable?
The stable source contains an iTerm2 OSC 1337 handler and rendering path.
Can I rely on Sixel and Kitty graphics in stable?
No. Their sequences are intercepted, but the stable rendering code marks decoders and Kitty state management as future work.