• tal@lemmy.todayEnglish
    6·
    6 days ago

    On one hand, kitty is doing a very aggressive job of advancing the terminal world.

    • Providing protocol extensions to permit terminal software to use more modifier keys than were available in the past, which is something that I really wanted to see.

    • Providing a newer graphics protocol than the ancient Sixel — which kitty also supports. Terminal software can render images — mpv can even (slowly) play movies in-terminal using said protocol.

    • It can leverage the GPU for acceleration.

    On the other hand, it’s got some things that I don’t like:

    • By default, it phones home. I really do not like software doing this.

    • It keeps attracting new functionality at a very rapid rate, much of which is on by default, and many of which I don’t know if I want. There are a bunch of modules (“kittens”), and a lot of functionality (including aiming to be tmux-like) that I don’t know if I want in a virtual terminal program. This increases the attack surface, which is something I’m kind of sensitive about for a program that’s intended to sandbox content from remote systems. xterm has a lot of cruft related to older protocols and features too, but at least that’s pretty mature code…and it still has had a bit of a security history.

    • The startup time isn’t great. urxvt can run a daemon, urxvtd. foot just starts up quickly on its own. Kitty can do kitty -1, which makes subsequent windows open quickly, but close all open terminal windows, and you’re back to the window taking a noticeable amount of time to come up.

    • I’m not sure about the merits of another extension, its ability to render differently-sized fonts in-terminal. That seems like it might fragment terminal software into being able to run on a grid-based set of characters and not.

    I spent a while using it and then went back to foot. There’s just very little that I actually want to do and would take advantage of that foot can’t do (though to be fair, I might make more use of the graphics protocol if tmux supported it — the closest one can get graphics-wise there is a non-mainline tmux fork with experimental Sixel support).

    If tmux supported the kitty graphics protocol and then some emacs packages also added support — a lot of those have the ability to use graphics, but will only do so in a non-terminal environment — that could take me back to kitty, though.

      • tal@lemmy.todayEnglish
        2·
        5 days ago

        I have — at one point or another, I’m pretty sure that I’ve tried every Linux virtual terminal program out there that’s been packaged for major distros in the past twenty years — but it was some time back, and I don’t remember specifics. For me, time to start and text throughput was a pretty dominant factor, and urxvt (for X11) or foot (for Wayland) ranked highly there.

          • tal@lemmy.todayEnglish
            4·
            5 days ago

            Don’t take this as zinging alacrity as unusual or whatever. I mean, I don’t care about tabs, for example, because I do “tabs” inside the terminal, using tmux, so I’m fine using something like urxvt, foot, or alacrity, but many people don’t, and care a bunch about having multiple tabs in a virtual terminal program. Time to open terminals, which I care about, may not matter much if you launch them with the mouse instead of whacking a key combination – by the time your fingers get back to the keyboard, the terminal is probably up.

            Most virtual terminal programs work more-or-less the same way, outside something exotic like cool-retro-term, and you’ll be fine with choosing any of them.

            • L3ft_F13ld!@lemmy.dbzer0.comEnglish
              3·
              5 days ago

              Yeah I didn’t read it as a negative at all, but thanks for explaining anyway. Never got to the point of seriously trying tmux yet, but I will eventually. I understand it does more than just “tabs in your terminal”.