[kitty] Problem in has_local_support

[UltimateNyn]

I tried using viu as backend for vifm to preview images but found out weird behavior (vifm/vifm#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 add return Ok(());

[Testare]

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]

I know it's been ages, but I had a closer look today and I think the changes from e754e4d should make the temp file deletion much more reliable. Unfortunately, I wasn't able to reproduce the issues you were facing, so it will be greatly appreciated if anyone is able to test the patch and let me know. Thanks!

[UltimateNyn]

I tried the commit but sadly the issue persists. I would assume some wrong data gets sent to kitty and that causes the problem but sadly I currently don't have a lot of time to investigate the issue and since I don't plan on using vifm anymore I don't really need this to get fixed.

But when I find some spare time I might try poking around and trying to get some debug data or a setup to reproduce it

[atanunq]

Thank you for the feedback!

For future reference, the previous behaviour might have polluted your /tmp/ directory with a ton of viuer files. It might be the reason why the new code will not be able to even start. Deleting them manually is advised.