Module kitty 

The kitty graphics protocol, in the two sequences this needs.

What is sent

An APC — ESC _ G <keys> ; <payload> ESC \ — carrying the canvas as base64 RGB, split into chunks of at most [CHUNK] payload bytes with m=1 on every one but the last. The keys say what the bytes are (f=24, s, v), where they go (a=T, c, r) and how to behave (i, q=2, C=1).

The three keys that are not about the picture

• q=2 suppresses the terminal’s reply, and it is not an optimisation. Without it the terminal answers every transmission with ESC _ G i=… ; OK ESC \ on stdin, which arrives in the event loop as a burst of keystrokes — an i, an =, a ;, an O, a K. Half of those are bound. A picture that types into the tree it is a picture of is not a degradation, it is a hazard.
• C=1 stops the cursor moving. The default is for the cursor to end up after the image, which ratatui does not know about and would then draw from.
• i= names the image so it can be taken back. See Image::gone: a graphics image is stored by the terminal, not by this process, so leaving one behind is leaving a megabyte in somebody’s terminal after pristine has exited — #619’s “a state that cannot be given back is a state you do not take”, in the one place here where the state lives in another program’s memory.

Nothing here asks the terminal a question

There is a documented query for “do you speak this protocol” and it is a round trip: write a probe, then read the answer, with no bound on how long a terminal that does not speak it takes to not answer. That is exactly the blocking probe super::super::chrome refuses to make, so this is allowlisted from the environment on the same terms as everything else — see [super::Graphics].

Structs

Image

Everything this sends the terminal, as bytes ready to be written.

Constants

ID

An image this process has given the terminal, and the id it can take it back by.