Kitty: Test for protocol support & wait for "OK" on print

[hasezoey]

This PR implements actually protocol testing for the Kitty Graphics Protocol, instead of testing for known TERM environment variables, which could be misleading and lead to #70.
Additionally, while i was at it and noticed it, i made it so that printing a image waits until the terminal responds, as otherwise it could lead to a race condition, which in viu could manifest as never actually displaying the image at all.
To do this response, i had to add i=10 (image identifier), as otherwise kitty seemingly does not respond at all.

And finally, also fix a issue of all functions that interact with a temporary file and attribute t=t returning a error, when actually everything was working correctly. This was due to Kitty terminals on temporary files deleting after finishing reading them:

t=t A temporary file, the terminal emulator will delete the file after reading the pixel data
Source: The transmission medium

This fixes:

• fixes Query Kitty image support #67
• fixes Infinite loop in Kitty+ZelliJ #70 by not having the protocol supported
• fixes Enable Kitty image protocol for Warp #71 as this is now automatic, if the terminal properly implements it

Additionally, from my testing, this now supports KDE-Konsole with kitty protocol, though it only seems to support the Remote display method (the other returns a error with NOT SUPPORTED).

TL;DR:

• check kitty protocol support instead of environment variable TERM
  • supports more terminals now
• fix race-condition printing and displaying the image
• fix error when everything was working correctly

[hasezoey]

I had 2 mistakes that lead me to force-push more than i wanted:

• on the first commits, i had not run the tests at all, so i didnt catch the infinite-loop of never getting any response while in tests (fixed via test utils)
• then, i had only run the kitty tests (cargo test kitty) and not the full normal test suite, not catching doctest at lib.rs@14 to cause out-of-memory errors (due to now supporting kitty protocol on Konsole); this was due to not exiting on the first Unknown key in supports_kitty_protocol

Though the infinite-loops still continue to exist if there is some unexpected environment, should we maybe add some kind of fallback (timeout and/or too much response data)? (Note that this is the same behavior as before the PR currently)

[atanunq]

Additionally, while i was at it and noticed it, i made it so that printing a image waits until the terminal responds, as otherwise it could lead to a race condition, which in viu could manifest as never actually displaying the image at all.
To do this response, i had to add i=10 (image identifier), as otherwise kitty seemingly does not respond at all.

I don't understand when that happens.

As a result of using the same id of 10, only the last picture is shown. If you run viu a few times and scroll up, they will have been replaced.

[hasezoey]

Additionally, while i was at it and noticed it, i made it so that printing a image waits until the terminal responds, as otherwise it could lead to a race condition, which in viu could manifest as never actually displaying the image at all.
I don't understand when that happens.

The state i was in when starting this PR was that the Kitty terminal was always detected for Remote, even though it should have supported Local too.
After i had gotten the Kitty terminal to be detected for Local due to the file "NotFound" error (see commit fix(kitty): dont error on non-existed temporary file after print), i had noticed that sometimes for (at the time) unexplainable reasons it just sometimes would print nothing and other times will when running viu.
Then i tried to just see if catching a response from the terminal would be available, but (without the i= set yet) the terminal did not respond, but due to this i noticed that it was now drawing 100% (though with a bit of delay since starting the application). So instead to verify this was a race-condition, i added a simple std::thread::sleep(10s) and it also "just worked" consistently.
After some fiddling around, i had found that when i added i= to the command line, the terminal did start responding with OK which was always after the image had been displayed, so i added that.

I did not know that multiple images should be displayable at once via viuer though, what would you propose to fix this and maybe still be user controllable? Should we maybe expose setting the ID to the user, with a default provided in Config(with naming along the lines of kitty_id)? (this could implicitly and in a indirect way allow #28 for kitty)

Note: i was (and still am for this PR) running a locally modified viu which uses the local viuer and disable all possible other protocols other than kitty.

[hasezoey]

@atanunq I think this PR is still ready, or do you still have problems with it like mentioned in #79 (comment)? Should i move some code (like the ReadKey trait and resulting tests) into a separate PR so that it can be merged earlier than this i=10 discussion / identifier implementation?

[hasezoey]

I have decided to split this PR into multiple parts (like mentioned in my last comment), so i will convert this to be a DRAFT again.

[hasezoey]

Additionally, while i was at it and noticed it, i made it so that printing a image waits until the terminal responds, as otherwise it could lead to a race condition, which in viu could manifest as never actually displaying the image at all.
To do this response, i had to add i=10 (image identifier), as otherwise kitty seemingly does not respond at all.

I think i found a workaround that does not require a identifier (i=10), we can wait until the OK from the terminal (if it responds / if a identifier is provided in the future) AND we can send \x1b[5n (Device Status Report (DSR)), which practically all terminal respond with (response is \x1b[0n), so we dont wait infinitely.
Example, kitty would respond with (without setting i=):

KittyResponse([UnknownEscSeq(['[', '0', 'n'])])

With setting i=:

KittyResponse([UnknownEscSeq(['_']), Char('G'), Char('i'), Char('='), Char('1'), Char('0'), Char(';'), Char('O'), Char('K'), UnknownEscSeq(['\\']), UnknownEscSeq(['[', '0', 'n'])])

The same is true for Konsole.

I found this sequence while trying to look if iterm2 has a "check protocol support" thingy too, via it2check:

# Report device status. Responds with esc [ 0 n. All terminals support this. We
# do this because if the terminal will not respond to iTerm2's custom escape
# sequence, we can still read from stdin without blocking indefinitely.
echo -n '�[5n'

I guess alternatively we could also use the \x1b[c (Send Device Attributes (Primary DA)) query (like kitty detect) instead of the device status, though that would be more replied bytes.

PS: it turns out there still is no correct way to detect iterm2 protocol support (and only TERM environment checking is possible for other than iterm2 itself (wezterm does not reply to \x1b[1337n))

[hasezoey]

I am gonna close this PR as practically every part has been re-done in smaller PRs (re #85, #86, #87, #90)