Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of Terminal Emulators in 2025: The Errant Champions

jeffquast.com

Post reply on HN
Print view View original

71–80 of 283 posts

Re: State of Terminal Emulators in 2025: The Errant Champions

#71

Post by bee_rider »

embedding-shape wrote: post #9
skerit wrote: post #7

I see Ghostty does not support (and does not plan on adding support for) Sixels, instead preferring the Kitty image protocol. Now if the Kitty image protocol is so great and the Sixel stuff is so bad, ~~why is it only used in Kitty and Ghostty?~~ *Edit: it's also supported in Konsole, WezTerm, ... but still I'm interested in why we have 2 competing protocols right now.

> Now if the Kitty image protocol is so great and the Sixel stuff is so bad, why is it only used in Kitty and Ghostty? Images as in "pictures" or is that something else? I'm using Alacritty, and I don't think I've once thought "I need to see this image inside the terminal" and I do deal with images and frames from videos a lot. Probably if I saw it being added to Alacritty I'd think it was adding unnecessary bloat, s…

It would be nice if matplotlib or Octave could display pretty plots and figures on a remote server, in the terminal.

Re: State of Terminal Emulators in 2025: The Errant Champions

#72

Post by zokier »

IshKebab wrote: post #27
skerit wrote: post #7

I see Ghostty does not support (and does not plan on adding support for) Sixels, instead preferring the Kitty image protocol. Now if the Kitty image protocol is so great and the Sixel stuff is so bad, ~~why is it only used in Kitty and Ghostty?~~ *Edit: it's also supported in Konsole, WezTerm, ... but still I'm interested in why we have 2 competing protocols right now.

IMO none of them are particularly useful. Sixels is hilariously inefficient. Kitty is slightly better because you can send data as PNG, but ... you have to send image data as PNG! I wish there was a high performance way of remoting graphics over SSH. How cool would it be if you could SSH to a remote machine and it just showed you the remote desktop in the terminal itself? No messing around with port forwarding, weird…

One of my pet proof of concept projects is figuring out how to ergonomically tunnel web apps over ssh without needing to fiddle with listen ports and port forwards. First attempt was to push http2 over stdio which actually worked, but it didn't really integrate well with terminal use. Currently I think similar approach to X forwarding makes sense, where SSH forwards one unix socket over ssh connection and then the applications can connect to that socket and put http2 traffic over that connection. Basically the idea is to make webapp tunneling as easy as X tunneling, so you can just type command in shell and (browser) window would pop open without any extra hassle. The neat thing is that because http2 has persistent connections with multiplexing etc built in, it works really well for this sort of hack; plain http 1.0 would be far more annoying.

Re: State of Terminal Emulators in 2025: The Errant Champions

#73

Post by ac29 »

christophilus wrote: post #57

Foot is excellent. Wayland only, but it is very fast to launch, and uses few resources. I love it.

Yep this is my current favorite too. I liked ghostty when I evaluated it, but for some reason it uses an order of magnitude more memory than foot to display a single, empty terminal.

Re: State of Terminal Emulators in 2025: The Errant Champions

#74

Post by shiomiru »

skerit wrote: post #7

I see Ghostty does not support (and does not plan on adding support for) Sixels, instead preferring the Kitty image protocol. Now if the Kitty image protocol is so great and the Sixel stuff is so bad, ~~why is it only used in Kitty and Ghostty?~~ *Edit: it's also supported in Konsole, WezTerm, ... but still I'm interested in why we have 2 competing protocols right now.

Sixel came earlier, and already fulfilled the basic requirement of "put pixels on screen in a single well-defined format" (something not even iTerm2's protocol does.)

Kitty is a lot more complex: it accepts five different encodings, has three different ways to load the data, supports animations, etc. So it's no wonder only a few terminal developers had time to implement it.

See also: https://github.com/veltza/st-sx/issues/1#issuecomment-190272... 5000 lines (Kitty) vs 1000 lines (Sixel) even though the Kitty patch is just a "subset".

Re: State of Terminal Emulators in 2025: The Errant Champions

#75

Post by imiric »

cb321 wrote: post #68

`st` used to have a patch set for sixel graphics on its web site. I use an old version all the time to do gnuplots in terminals with nice scrollback. It seems to have been retired in favor of the kitty graphics protocol.

This[1] is an up-to-date fork with sixel support, and a few other patches.

IMO it's unfair to compare barebones `st` with fully-featured terminals. The entire point of `st` is for users to apply their own patches to it, which does make it difficult to compare, since there's no standard version of it.

`st` is a pretty great terminal. I switched to `foot` when I migrated to Wayland a few months ago, but not for any practical reasons other than wanting to rely less on Xwayland.

[1]: https://github.com/veltza/st-sx

Re: State of Terminal Emulators in 2025: The Errant Champions

#79

Post by [deleted] »

skerit wrote: post #7

I see Ghostty does not support (and does not plan on adding support for) Sixels, instead preferring the Kitty image protocol. Now if the Kitty image protocol is so great and the Sixel stuff is so bad, ~~why is it only used in Kitty and Ghostty?~~ *Edit: it's also supported in Konsole, WezTerm, ... but still I'm interested in why we have 2 competing protocols right now.

[deleted]

Re: State of Terminal Emulators in 2025: The Errant Champions

#80

Post by cb321 »

imiric wrote: post #75
cb321 wrote: post #68

`st` used to have a patch set for sixel graphics on its web site. I use an old version all the time to do gnuplots in terminals with nice scrollback. It seems to have been retired in favor of the kitty graphics protocol.

This[1] is an up-to-date fork with sixel support, and a few other patches. IMO it's unfair to compare barebones `st` with fully-featured terminals. The entire point of `st` is for users to apply their own patches to it, which does make it difficult to compare, since there's no standard version of it. `st` is a pretty great terminal. I switched to `foot` when I migrated to Wayland a few months ago, but not for any pra…

I 100% agree `st` is pretty great and comparing bare bones is unfair.

Thanks for that link! I suppose I should have provided a link to the variant I use which is https://github.com/bakkeby/st-flexipatch though I do have like 14 of my own private patches. :-) Because it really is a simple, hackable codebase.

I will say, though, that I doubt there are many unicode conformance patches floating about. I don't know though, and I haven't looked.

Post reply on HN