Infinite loop in Kitty+ZelliJ

[hasezoey]

viuer v0.9.1
zellij 0.42.0
kitty 0.40.0

Some users in termusic have noticed that with the Kitty+ZelliJ combinations, the TUI gets stuck.
I investigated and narrowed it down to the following infinite loop as it never gets a response or has a timeout:

viuer/src/printer/kitty.rs

Lines 94 to 102 in 56e9e51

	while let Ok(key) = term.read_key() {
	// The response will end with Esc('x1b'), followed by Backslash('\').
	// Also, break if the Unknown key is found, which is returned when we're not in a tty
	let should_break = key == Key::UnknownEscSeq(vec!['\\']) || key == Key::Unknown;
	response.push(key);
	if should_break {
	break;
	}
	}

Note that this executed as TERM is xterm-kitty.

This might be fixed when #67 is implemented and proper querying is done as suggested in https://sw.kovidgoyal.net/kitty/graphics-protocol/#querying-support-and-available-transmission-mediums:

We intend that any terminal emulator that wishes to support it can do so. To check if a terminal emulator supports the graphics protocol the best way is to send the above query action followed by a request for the primary device attributes. If you get back an answer for the device attributes without getting back an answer for the query action the terminal emulator does not support the graphics protocol.

This means that terminal emulators that support the graphics protocol, must reply to query actions immediately without processing other input. Most terminal emulators handle input in a FIFO manner, anyway.

So for example, you could send:

<ESC>_Gi=31,s=1,v=1,a=q,t=d,f=24;AAAA<ESC>\<ESC>[c

If you get back a response to the graphics query, the terminal emulator supports the protocol, if you get back a response to the device attributes query without a response to the graphics query, it does not.

As, to my understanding, any terminal will reply to this, and depending on the response it can be determined what the terminal supports without a temp file.

I might also be completely wrong and with the current implementation ZelliJ should return some escape sequence.

Original issue: tramhao/termusic#451

[hasezoey]

I just did a small rust try, the following code response includesG=31;OK if supported, and a different response if not:

fn main() {
    eprintln!("BEGIN");

    print!("\x1b_Gi=31,s=1,v=1,a=q,t=d,f=24;AAAA\x1b\\\x1b[c");
    let _ = std::io::stdout().flush();

    let term = console::Term::stdout();

    while let Ok(key) = term.read_key() {
        eprintln!("KEY: {:#?}", key);
    }
}

Instead of having a infinite loop with no response ever.

Actual response in console terms

In case it is supported, executed on kitty:

BEGIN
KEY: UnknownEscSeq(
    [
        '_',
    ],
)
KEY: Char(
    'G',
)
KEY: Char(
    'i',
)
KEY: Char(
    '=',
)
KEY: Char(
    '3',
)
KEY: Char(
    '1',
)
KEY: Char(
    ';',
)
KEY: Char(
    'O',
)
KEY: Char(
    'K',
)
KEY: UnknownEscSeq(
    [
        '\\',
    ],
)
KEY: UnknownEscSeq(
    [
        '[',
        '?',
        '6',
    ],
)
KEY: Char(
    '2',
)
KEY: Char(
    ';',
)
KEY: Char(
    'c',
)

In case it is not supported, executed on alacitty:

BEGIN
KEY: UnknownEscSeq(
    [
        '[',
        '?',
        '6',
    ],
)
KEY: Char(
    'c',
)

Another not supported case, executed on kitty+zellij:

BEGIN
KEY: UnknownEscSeq(
    [
        '[',
        '?',
        '6',
    ],
)
KEY: Char(
    '2',
)
KEY: Char(
    ';',
)
KEY: Char(
    '4',
)
KEY: Char(
    'c',
)

[Android789515]

I am experiencing this issue when running in Zellij.

[hasezoey]

I can confirm that #79 will fix this issue for my case and system, @Android789515 if you can, could you try PR #79 and report back?