I was just looking at terminals, because I wanted a Wayland-native terminal. I was happy with urxvt, but it hasn’t been ported to Wayland.
Kitty supposedly follows a lot of security-conscious practices, but it also has a metric shit-ton of features that let the remote end affect local behavior, and turns everything almost everything on by default, which makes me really nervous.
Both alacritty and foot eventually segfaulted when I tried playing a movie using the tct vo= option to mpv, which makes me nervous about how solid they are at handling even well-formed input.
(Aside: foot did fine with playing movies with vo=sixel, which was a surprise.)
I also learned that GNU screen and tmux do not understand sixel, the output from vo=tct, all the new keyboard and graphics protocols that Kitty has introduced, and such.
I kind of feel like there’s a need for some sort of fast generic terminal parsing engine or at least a language for describing protocols that they could all use, something that lets them gracefully ignore protocols that they don’t understand, because otherwise they do an abymal job of dealing with them.
Really, I’d rather have a thin virtual terminal, more like foot than Kitty, and put more logic into something like screen or tmux.
Some of what Kitty does has to be in Kitty, like new protocols for handling keys and key combinations that traditionally couldn’t be sent to terminals. IIRC it has some mechanism for fast display of video images via shared memory between the terminal and locally-running software (though my experience was that mpv with vo=kitty was terribly slow, so it may or may not actually be using shared memory).
But some, like console-based tabs and windows (kind of like GNU screen’s windows and windows with splitting) really don’t need to be in a terminal. It’s a lot of stuff to expose to a remote system.
You also have Kitty involving itself in running local commands when the mouse interacts with text in the terminal. A protocol to permit password-authenticated remote control, from the far end, of Kitty. Python modules. Permitting clipboard access from the remote end. File transfer initiating from the remote end overwriting local files. Scraping and being driven by a lot of shell information from the remote end. Opening URLs.
I mean, on one hand, Kitty is doing a lot to make console programs, including across hosts, a lot more powerful than additions that anyone has done in years.
But on the other hand, a lot of this sets off “this looks like very fertile ground for security problems” red flags to me.
I kind of wish that there were a standard virtual terminal testing program. Like, let it run lots of tiny tests and be able to take a screenshot of the output, compare to expected output. As long as terminals can have options to produce standard output (trim borders, use the same font, use the same default 16 colors for the base 16 colors), their output should at least potentially be able to be pixel-identical if their support is correct.
I was just looking at terminals, because I wanted a Wayland-native terminal. I was happy with urxvt, but it hasn’t been ported to Wayland.
Kitty supposedly follows a lot of security-conscious practices, but it also has a metric shit-ton of features that let the remote end affect local behavior, and turns
everythingalmost everything on by default, which makes me really nervous.Both alacritty and foot eventually segfaulted when I tried playing a movie using the
tctvo= option to mpv, which makes me nervous about how solid they are at handling even well-formed input.(Aside: foot did fine with playing movies with vo=sixel, which was a surprise.)
I also learned that GNU screen and tmux do not understand sixel, the output from vo=tct, all the new keyboard and graphics protocols that Kitty has introduced, and such.
I kind of feel like there’s a need for some sort of fast generic terminal parsing engine or at least a language for describing protocols that they could all use, something that lets them gracefully ignore protocols that they don’t understand, because otherwise they do an abymal job of dealing with them.
Really, I’d rather have a thin virtual terminal, more like foot than Kitty, and put more logic into something like screen or tmux.
Some of what Kitty does has to be in Kitty, like new protocols for handling keys and key combinations that traditionally couldn’t be sent to terminals. IIRC it has some mechanism for fast display of video images via shared memory between the terminal and locally-running software (though my experience was that mpv with vo=kitty was terribly slow, so it may or may not actually be using shared memory).
But some, like console-based tabs and windows (kind of like GNU screen’s windows and windows with splitting) really don’t need to be in a terminal. It’s a lot of stuff to expose to a remote system.
You also have Kitty involving itself in running local commands when the mouse interacts with text in the terminal. A protocol to permit password-authenticated remote control, from the far end, of Kitty. Python modules. Permitting clipboard access from the remote end. File transfer initiating from the remote end overwriting local files. Scraping and being driven by a lot of shell information from the remote end. Opening URLs.
I mean, on one hand, Kitty is doing a lot to make console programs, including across hosts, a lot more powerful than additions that anyone has done in years.
But on the other hand, a lot of this sets off “this looks like very fertile ground for security problems” red flags to me.
I kind of wish that there were a standard virtual terminal testing program. Like, let it run lots of tiny tests and be able to take a screenshot of the output, compare to expected output. As long as terminals can have options to produce standard output (trim borders, use the same font, use the same default 16 colors for the base 16 colors), their output should at least potentially be able to be pixel-identical if their support is correct.