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

101–110 of 283 posts

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

#101

Post by toast0 »

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…

> 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 X servers, etc

I think there's at least three different experiences here, and they're all valid, but I don't know what you really want.

A) remote desktop --- connect to a fully formed desktop environment (with SSH to authenticate, I guess?), possibly persisted and/or shared so you can connect back and get into the same place or share with another user?

B) run a program remotely and display it on your local terminal; essentially remote X, but I gather you're looking for more performance and maybe some other nice to haves? Maybe you want to transport audio too... Maybe you don't want the crap experience remote X has become since app developers don't spend any effort on it and you kind of get what you get, which is a lot of jank.

C) images in the terminal, with high performance. PNG should be ok for that, right? Maybe an extension for lossy compression might be nice depending.

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

#102

Post by chrysoprace »

Imustaskforhelp wrote: post #99
chrysoprace wrote: post #92

Earlier quoted context omitted.

I've always wanted to like Alacritty but they've had an open issue to support ligatures since 2017 and they're not in a rush to implement them. Now the only feature I need in Ghostty is Windows support.

> Now the only feature I need in Ghostty is Windows support. I use ghostty on my mac but have you forgot about ctrl + f to find things support in ghostty (I don't think it has ctrl f support iirc right?)

I'm always running tmux so it's not typically a feature I look for, but as you mention it doesn't seem to trigger a find for terminal scrollback. Wezterm doesn't do this either so maybe that's an iTerm thing. I always assume Ctrl keybindings will trigger emacs mode shortcuts in the tty.

Update: Windows Terminal doesn't do it either.

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

#103

Post by ashton314 »

alwillis wrote: post #89
hnlmorg wrote: post #39

Earlier quoted context omitted.

I thought built in theme pickers were the norm…?

The theme picker in Ghostty is above and beyond anything I’ve ever seen in a terminal.

Holy crap you’re right. I just found that and it’s amazing

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

#104

Post by epolanski »

zadjii wrote: post #40

No love for Windows Terminal? I know that linux has a much richer terminal ecosystem, but WT ranks a lot higher than a wide breadth of terminal emulators on linux now. Could anyone have imagined that 10 years ago?

I absolutely love it, it's my personal favorite. Using ghostty on MacOS instead.

But I'm no power user.

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

#105

Post by klooney »

mort96 wrote: post #85
alkh wrote: post #36

I have been pretty happy with Alacritty for a while but just tried Ghostty and am a little bit mind-blown. The fact that it has a built-in theme picker is insanely convenient for people working on multiple computers at the same time(so the same theme might not work everywhere). Overall, it literally looks like a better Alacritty alternative. The creator(s) did a great job!

The only thing I'm missing from ghostty is scrollback search. It's planned AFAIU, I hope it gets there eventually. Otherwise, ghostty has been pretty good. (I know you can fake scrollback search with tmux. It's not the same.)

There seems to be a contingent that just doesn't use scroll back search, which I find kind of baffling.

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

#106

Post by unleaded »

loph wrote: post #90

The list does not include DECterm. https://stuff.mit.edu/afs/net/dev/system/pmax_ul3/srvd.74/us... Maybe it's hard to find these days. However it had the best VT220 emulation I have seen running on X Window System. I will note that I have not seen a terminal emulator that supports the "double wide" and "double high, double wide" character modes of the VT100. Those giant letters were kinda fun. ( #3, #4, and #6 if my…

strangely enough Windows Terminal supports DECDHL but barely any on Linux do!

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

#107

Post by [deleted] »

topaz0 wrote: post #87
ubercow13 wrote: post #81

Earlier quoted context omitted.

Seems quite hard to avoid - file management such as running "ls" where any filename has any non-ascii character such as a CJK or accented letter - editing any text file in a terminal editor that isn't 100% ascii - viewing/printing any data from any source, such as a log file/the web/'curl'ing something, where any language other than English or non-ascii character is used - using various modern command line tools that…

It would be different if I worked in chinese or hindi or something, or worked with other people who do. Also worth noting that even terminals that score badly on this benchmark handle most of the things you mention just fine (e.g. accented characters or check marks -- unicode that is well-behaved in terms of mapping a single code point to a single fixed width character). The places where the poorly ranked terminals l…

[deleted]

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

#108

Post by epolanski »

hnlmorg wrote: post #82
ubercow13 wrote: post #81

Earlier quoted context omitted.

Seems quite hard to avoid - file management such as running "ls" where any filename has any non-ascii character such as a CJK or accented letter - editing any text file in a terminal editor that isn't 100% ascii - viewing/printing any data from any source, such as a log file/the web/'curl'ing something, where any language other than English or non-ascii character is used - using various modern command line tools that…

> using various modern command line tools that insist on printing emojis in their output Ugh. Unpopular opinion this but I personally find this practice repugnant. Same for when used in git commit messages, CI/CD task names and other such places. It just cheapens the quality of the product in my opinion Graphical characters and symbols like ticks I’m fine with. I have no objection to people wanting to make the termin…

Emojis are useful as visual indicators, there's anything from flags to check marks in them.

They can be super helpful to decorate CLI output.

If it feels juvenile but is helpful (as in many cases is) good.

Sure, some CLIs may over do with rockets and such, but any tools can misused.

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

#109

Post by altairprime »

dgl wrote: post #91
loph wrote: post #90

The list does not include DECterm. https://stuff.mit.edu/afs/net/dev/system/pmax_ul3/srvd.74/us... Maybe it's hard to find these days. However it had the best VT220 emulation I have seen running on X Window System. I will note that I have not seen a terminal emulator that supports the "double wide" and "double high, double wide" character modes of the VT100. Those giant letters were kinda fun. ( #3, #4, and #6 if my…

xterm does and some others, I posted about this and emojis a while ago: https://dgl.cx/2025/06/can-your-terminal-do-emojis

(161 comments) https://news.ycombinator.com/item?id=44362272

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

#110

Post by AceJohnny2 »

dmd wrote: post #59
Asooka wrote: post #13

I wonder how long until terminals support half of the XWindows protocol (as some weird combination of Markdown, HTML and escape codes, most probably). This is not a diss, I would actually be pretty happy with a pared-down GUI protocol in the terminal with extensive Unicode support.

well iTerm2 now has a #&*%( web browser built in...

Does "calling a system provided-component" (WKWebView) count as "built-in"?
Post reply on HN