Skip Navigation

You're viewing a single thread.

6 comments

  • 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.

    • Have you tried Alacritty? And if you have, what are your opinions of it compared to Kitty?

      • 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.

        • Good to know, thanks. As a noob any information is useful to me.

          • 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.

            • 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".

6 comments