- Work had me using the Windows Terminal for the first time ever after a life of developing on Linux. I got immediately hooked on the smart Ctrl+C and Ctrl+V (without needing to use Shift like on Linux!)
For those not knowing, Windows Terminal uses Ctrl+C to abort the current process (as we'd expect) when nothing is selected, but copies when there is a selection. Similarly, Ctrl+V just pastes. So convenient!
- 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 -nomouse vt102 -rs232 null_modem -bitb socket.localhost:1234
You can do the same thing with a vt220.I've had an idea to try to write a sort of high-level-ish VT220 emulator that pokes and patches the ROMs and the system to let you control it with the mouse, paste and stuff, lets you just doubleclick it to get a terminal, etc... I forgot about that until seeing this. Nobody would use it for more than 5 minutes but it would be funny.
- Pretty nice to see KDE's Konsole rank really high, especially if you take performance/test elapsed time into account. Considering it's a decades-older workhorse compared to the new star ghostty, not too shabby that it's kept up.
- Some vaguely related things:
- VTTEST <https://invisible-island.net/vttest/vttest.html>, which tests capabilities from VT-100 to VT-520 terminals.
- Markus Kuhn's UTF-8 test <https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt>.
- I used iterm2 for ages, but then somehow defaulted to terminal.app. It is fast and that is basically all i need from a terminal emulator, everything else is taken care of by tmux.
by eschatology
0 subcomment
- 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?
- 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 stuff and sysadmin. We have other ways of doing things remotely like html that might be more appropriate for ZWJ emoji and languages with complicated text shaping/rendering.
- 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!
- I appreciate this analysis is on the state of terminal emulators, but I'm curious how well the integrated terminals that come bundled in code editors/IDEs also perform. For example, where does Zed's integrated terminal fit in the rankings? VS Code (and its derivatives)? JetBrains, Sublime Text?
- I'd like to see the key-to-pixel latency speed championship.
- 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?
by christophilus
3 subcomments
- Foot is excellent. Wayland only, but it is very fast to launch, and uses few resources. I love it.
- funny how we've got more terminal choices than ever but most devs still just use whatever came with their OS.
the real test isn't feature count - it's whether switching costs are worth it. for most people, learning new shortcuts and configs is more painful than missing sixel support they'll never use.
- So the state of 2025 then tests a VTE that is from 2023? 4 major releases behind? And through a GTK 3 app, not even a GTK 4 one which will use the GPU?
- The table seems wrong. Xterm supports sixels.
by ivanjermakov
0 subcomment
- 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...
by sanskarix
1 subcomments
- the terminal wars are hilarious because 99% of the time you're just running the same bash commands. people spend hours configuring unicode width handling when their actual workflow is git, ssh, and maybe docker.
I switched from iTerm to whatever came default on my new machine and honestly couldn't tell you what I'm missing. unless you're doing something weird with sixels or rendering full images in your terminal (why?), it doesn't matter.
the only thing that actually matters: does it not lag when you cat a big file by accident? can you copy paste without wanting to throw your laptop? everything else is bike-shedding.
- The terminal that comes with macOS version ends on the 29th place in the results.
- I'd find it very useful to be able to query a terminal to see if it has font support for a given list of characters.
This would allow TUIs to use recent unicode characters which may not be supported (e.g. Symbols for Legacy Computing), or private use characters (e.g. powerline symbols & font-awesome icons), while falling back to a more universally supported character in terminals that do not support them.
- a look at terminal emulators
https://lwn.net/Articles/749992/
https://lwn.net/Articles/751763/
- 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.
- 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. (<esc>#3, <esc>#4, and <esc>#6 if my memory serves me right.)
- I can't remember the last time I used a non-ascii character in the terminal. I know that's not the case for everyone, and they deserve good terminals too, but it does mean that the criteria measured here have no relevance to my choice of a good terminal for me.
- While there's vscode console, I think that bare Xterm.js would be a nice addition to the list.
- The same part of me that is shy to install Chrome extensions is shy to try non-standard terminals. I'd like the thing I type my passwords into to be as trusted as possible.
SteamOS comes with Konsole, so that's what I've got installed in Linux. What am I missing out on by not using e.g. Ghostty?
(I know this article is about Unicode support, but I don't think I've ever had a hard time using a terminal because of its level of Unicode support.)
- `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.
- There isn't a single mention of vttest results.
by iammrpayments
1 subcomments
- I would use neovide over anything else if they supported macos tabs. It’s the termianl with the best font readability for me.
by electroglyph
1 subcomments
- no xterm.js? it's a very good cross-platform terminal emulator
- I still use PuTTY and a MAX232EACwhateverthefuck chip for embedded hardware stuff with a DB9 cable thats been plugged in and out more times than your mom on prom night.
Should I switch to something else or just keep on truckin?
- > And then my next windmill that I'm looking at is variable-sized text in the terminal. So when I'm catting a markdown file, I want to see the headings big.
Is this something people actually want?
One of the reasons I enjoy using the terminal is because the text is of a fixed size and monospaced. Even colors and bold text can be distracting at times. I certainly don't want my terminal to render Markdown...
I imagine the feature could be disabled, but still. I'm all for improving terminal UIs, but let's not turn them into a web browser.
- It's interesting that these are rankings, but in some cases the individual points are make or break for a given use case. For example, none of the emulators ranked higher than iTerm2 support Tek 4010 mode, which iTerm2 does support. So that's the one I keep using.
- 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.
- [flagged]
by scuderiaseb
3 subcomments
- Nothing even mentioned on WezTerm really?
Hacker News