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

181–190 of 283 posts

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

#181

Post by lifthrasiir »

kevin_thibedeau wrote: post #153
shirro wrote: post #139

Terminal emulators are caught between emulating terminals and teletypes of the past and implementing new features and unicode is one of the struggles. The way most terminals and wcwidth handle the width of characters sometimes is not correct but preserving behavior is important for compatibility. It is possible that its just not worth trying to handle all unicode perfectly in a terminal. Its pretty good for legacy st…

For glyph width, there are codepoints classified as ambiguous width. These are mostly narrow pre-emoji symbols that have been extended with an alternate emoji representation. There's no way to predict what their width will be, even with explicit variation selectors which might just be ignored.

> These are mostly narrow pre-emoji symbols that have been extended with an alternate emoji representation.

Nitpick: this is incorrect. Easy counter-examples would be arrow symbols like →. UAX #11 helpfully explains what is "ambiguous" about those characters:

Ambiguous characters occur in East Asian legacy character sets as wide characters, but as narrow (i.e., normal-width) characters in non–East Asian usage. (Examples are the basic Greek and Cyrillic alphabet found in East Asian character sets, but also some of the mathematical symbols.) Private-use characters are considered ambiguous by default, because additional information is required to know whether they should be treated as wide or narrow.

In the other words, these characters have been commonly available in both Asian and non-Asian character sets and assigned different widths by them.

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

#182

Post by eschatology »

While the article title is true (errant is a very specific and concise word), to me it did not convey clear enough that this is just ucs-detect / unicode support (compliance?) ranking. The article title "State of Terminal Emulators in 2025" implied a larger comparison of terminal emulators than just ucs-detect.

Personally I also question the practicality or usefulness of this table because why should I care about having "the best unicode support"?

Curious, I briefly compared top ranked emulator (ghostty) on how fast it can print 10000 lines and it took 432ms compared to alacritty, ranked 18 (50ms), and Terminal.app, ranked 29 (50ms). If this is the trade-off to have the best unicode support, why should I want it? Why does it matter?

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

#183

Post by pmontra »

nitinreddy88 wrote: post #155
ajross wrote: post #147

Earlier quoted context omitted.

> I got immediately hooked on the smart Ctrl+C and Ctrl+V (without needing to use Shift like on Linux!) You, uh, never tried middle clicking?

So now we are moving away from Keyboard only Vim/Terminal thing to mouse for pasting?

Yeah, that slows down typing a lot. Luckily people on a laptop can use the touchpad which lies just below the space bar. I have a laptop with physical keys around the touchpad so I even have a button to paste. No need to tap, double tap, etc. I think that I never used a mouse in the last 20 years.

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

#184

Post by IshKebab »

toast0 wrote: post #101
IshKebab wrote: post #27

Earlier quoted context omitted.

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…

Yeah I want all of those. Only the third one really works at the moment but it's also the least useful. The second one I think would be the most transformative because then all the TUI apps people use like htop, ncdu and so on can have decent graphics.

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

#185

Post by IshKebab »

Brian_K_White wrote: post #60
IshKebab wrote: post #35

Earlier quoted context omitted.

There is though - the ssh authentication and connection is already handled, and I'm already in a terminal. When I quit the app or session I'm back in the terminal. If it worked it would greatly reduce the hassle. Think about all the TUI apps that exist. They're useful because they're convenient when working in a terminal, not because they look like shit.

If I want to view an image file on a remote machine, and all I have is ssh... I just connect to that machine with filezilla and click on whatever files I want. I can even open files that aren't PNG! Even files that aren't even images at all. Mindblowing. A terminal with in-band graphics primitives is called an RDP client. We've had graphics terminals since RIP BBS's and even before that. If they were actually useful…

I don't think viewing files is the most compelling use case for this.

> I just connect to that machine with filezilla

"Just" carries a lot of hassle, and this only applies to viewing files.

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

#186

Post by ivanjermakov »

Unicode support in terminals is kind of a mess for TUI software developers. There is no good way to know how many columns a Unicode character will take, because terminals use different grapheme clustering algorithms.

For a text editor I'm making I ended up with:

> Unicode support is limited to what common modern terminal emulators support. In Hat, "character" is a Unicode codepoint. So no grapheme clustering, no variation selection, no ZWJs, no terminal emulator-specific logic. As long as every buffer byte is displayed and editable, we're ok.

https://github.com/ivanjermakov/hat/blob/master/CONTRIBUTING...

And I do basic codepoint range check to find its approximate width: https://github.com/ivanjermakov/hat/blob/00782dbaee1e1a814ce...

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

#187

Post by colordrops »

Imustaskforhelp wrote: post #118
chrysoprace wrote: post #102

Earlier quoted context omitted.

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.

I would love to use tmux. I have used yazi in the past and I really liked it but I was barely using it to its fullest potential. I think I have "skill issue" regarding tmux and I used to use hyprland (recently went to niri) and I just always preferred opening up another terminal I used to use (which was foot back when I was using my own config and it was alacritty on cachy/ idk what was on omarchy for the time I was…

* use a prepackaged tmux config that makes it look nice and smooths out rough edges

* Spend some time learning keybindings and commands. Just an hour or two should be enough.

* Learn about the top plugins and install them. There's a plugin that saves and restores your session, I forget the name, but it's great

* If you use vim, set up both vim and tmux with the right plugins so that the same keybindings navigate across both vim and tmux splits seemlessly.

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

#189

Post by colordrops »

tristan957 wrote: post #124
ac29 wrote: post #73

Earlier quoted context omitted.

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.

Ghostty uses GTK + GPU rendering while Foot uses Wayland primitives and CPU rendering.

I've seen zero performance issues with foot.

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

#190

Post by p_l »

dgl wrote: post #130
unleaded wrote: post #111

It's interesting that none of the programs commonly known as "terminal emulators" actually emulate a terminal.. we can do that now though. https://zork.net/~st/jottings/Real-VT102-emulation-with-MAME... I would avoid doing the PTY thing and instead do this (works on WSL if MAME is the windows version): $ sudo socat TCP-LISTEN:1234,reuseaddr,fork EXEC:"/sbin/agetty -L - 9600 vt102",pty,setsid,ctty,stderr $ mame -nomou…

If MAME could support the VT525 (nearly the last terminal DEC made and unlike the previous DEC models it supports ANSI color) people might use it a bit more. It would be very useful for compatibility testing as there aren't many people with a real VT525! Last I looked someone had dumped the ROMs but there wasn't any support code.

VT5xx was the budget line with limited functionality, that's why only 525 among them supports ANSI color. The only fancy stuff was multisession (TD/SMP if you have all bits to support it) and "desktop accessories" like clock and calculator.

The really interesting ones are VT340 variants with ReGIS and full SIXEL graphics

Post reply on HN