I mean, ultimately more or less agree with you, in that software should work well for the user and do what the user wants. This is a case of this not happening. So, all things being equal, it's bad.

But things aren't all equal--there are tradeoffs at play. Kitty's choice to treat monospace fonts as actually monospaced may not fit everyone, but it's a valid decision in this design space.

hey, on X I read that MH has a lot of collaborators working on it (when making fun of Anti-AI stances) - looked at the repo: <5 people <5% of commits.

Honestly, as fun as it is using KGP, I don't consider it critical for any real use cases.

If you need a GUI, just use a GUI.

I mean, I share the sentiment, and IMO they should support at least the BSDs (there are official FreeBSD ports for both Kitty and Ghostty but no mentions of them in both websites)

Tbf, 'hardware accelerated' doesn't mean much when your text renderer is slow (which apparently seems to have been fixed after the 'Muratori drama': https://devblogs.microsoft.com/commandline/windows-terminal-...)

Print a massive log file in kitty/ghostty, and another one with you default terminal, and you'll see a massive difference in how fast the log is printed out. Well to be honest it's just comfort, I can't claim it makes a difference in actual productivity, for me the real benefits of kitty are just the terminal multiplexer-ish capabilities (panes, sessions), other rendering niceties like adjusting the font, or having smooth scroll, sensible default shortcuts. But the actual "performance" e.g. input lag or rendering lag, I don't think it's that important.

I frequently compile big software projects, using fast multi-core CPUs, like AMD 9950X, with which the compilation itself is really fast.

Such compilations produce a ton of text messages. With any classic terminal, the text rendering in the terminal window becomes a bottleneck, slowing down the compilation very noticeably.

With modern terminals that use GPU text rendering, like ghostty and kitty, compilations are done much faster.

Of course, with classic terminals you can redirect the compiler output, to avoid this problem, but I prefer to glance at the progress of the compilation, to notice early if there are problems.

Even in normal interactive use, there are enough cases when the difference between the instant rendering of ghostty or kitty and the slowness of the classic terminals is noticeable.

To see the difference between a slow terminal emulator, like you probably use, and a fast terminal emulator, you can do a "cat" from a text file of a few megabytes, and you will see the speed difference.

I have previously seen programs run much more slowly when launched from the built-in terminal in a JetBrains IDE because log output was blocked.

iterm2. When there's heavy logging, I've seen it lag. Doesn't feel as snappy as Kitty.