Testare
commented
1 year ago I've also come across this issue. In my case, I was trying to render images in the terminal as part of a terminal game, but the game would freeze when it tried to render the image.
I was using a kitty terminal as well. The game itself puts the terminal into raw input mode, alternate screen, and listens to the terminal event stream using the crossterm crate. This is done in a separate thread from the one displaying images, and based on the documentation for crossterm here (https://docs.rs/crossterm/latest/crossterm/event/index.html) it seems terminal input being handled by multiple threads causes issues.
Debugging as much as I could without a knowledge of kitty's protocols, it looks like to test if kitty has local support it sends some inputs to the terminal and listens to the output, but (probably for reasons above) it never gets that input, and so it gets stuck in a perpetual while loop.
If this is the only way to check for local support, I would love it if there was a way to "precompute" the local support so I could run the check before I start listening to keyboard input. Like a "verify_kitty_support" function that runs the local check beforehand and saves the result to a static OnceLock. That way I could run the local_support check before I take over the eventstream. I don't know if that'll help with the vim backend stuff though.
atanunq
UltimateNyn
I tried using
viuas backend forvifmto preview images but found out weird behavior (https://github.com/vifm/vifm/issues/814). After some searching in the code i found out that the problem originates from https://github.com/atanunq/viuer/blob/master/src/printer/kitty.rs#L72. Sadly I don't know enough about the Kitty image protocol or similar to fix it properly myself. For my local setup I will probably just addreturn Ok(());