How does this compare to Alacritty on Linux? I've been pretty happy with Alacritty for the past few years but I'm always interested in trying new things.
Alacritty is inspired by kitty; kitty being GPU accelerated (and alacritty also being GPU accelerated).
The major difference between them is that alacritty is written in rust (and has a really nice config that auto-reloads) and kitty is written in C with a smattering of python.
I feel like Kitty has less strange bugs due to its acceleration - e.g. font rendering is more consistent with the rest of the OS, I've had less issues with mouse and keyboard support, scroolback works, etc. It just feels like a more mature project while still providing most of the benefit.
I tried Alacritty some months ago also because of a HN post.
I think it lacks features compared to Kitty. At the very least tabs for multiple sessions and support for a transparent background made it not an option for me.
Kitty has replaced the standard terminal in Ubuntu for me, and I am quite happy with its performance and Unicode support.
As someone who is currently using Alacritty, and been since it first appeared on HN (years ago?), what specific features are you missing in Alacritty that Kitty has?
One thing about tabs, which ironically has come up now for Microsoft Windows Terminal, is that they do not fit at all well with the idea of application-resizable terminals, which has been the widely case for terminal I/O since the days of 80/132 column application-switchable terminals back in the 1970s. If (just to pick a mild example) one tab is a 24-line terminal and another is a 25-line terminal, they aren't the same size in the GUI.
Line up a row of real terminals, and of course they do not constrain one another, size-wise. Indeed, back in the 1990s the DTTerm terminal emulator pioneered the terminal emulators' abilities for applications to set any arbitrary size (within reason) for a terminal emulator.
I did a quick review of terminal emulators in light of this, and varyingly tabbed terminal emulators do not support application resizing (DECSLPP/DECSNLS/DECSCPP) at all or support it in limited, or at least odd (compared to real terminals), ways. Konsole, possibly the best of the bunch, implements resizing properly, leaving large margins when the requested terminal screen size does not match the GUI window size, but triggers a GUI resize whenever a tab receives the input focus back, so application-requested size changes do not last if one switches amongst tabs. One tabbed terminal emulator author is actively opposing the idea that terminals should be resizable by applications emitting these control sequences, completely reversing course from DTTerm's innovation.
The problem for Windows Terminal is compounded by the fact that it isn't just supporting terminal I/O applications, it is supporting console I/O applications. In console I/O not only can applications set the screen buffer size at whim, they can also set the window rectangle. Not supporting either is a huge and very noticable step backwards, by over three decades, for Windows TUI applications that Windows Terminal is aimed to be compatible with.
A tabbed UI is not a universally unproblematic thing when it comes to terminal emulators. (-:
The major difference between them is that alacritty is written in rust (and has a really nice config that auto-reloads) and kitty is written in C with a smattering of python.