State of Terminal Emulators in 2025: The Errant Champions

https://www.jeffquast.com/post/state-of-terminal-emulation-2025/

by SG- • 9 months ago

267 271 9 months ago

audidude• 9 months ago

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?

embedding-shape4• 9 months ago

Which one is that about specifically? Maybe the author could fix it.

Compared the results (https://ucs-detect.readthedocs.io/results.html#general-tabul...) with what I use day-to-day (Alacritty) and seems the results were created with the same version I have locally installed, from Arch/CachyOS repos, namely 0.16.1 (42f49eeb).

milliams• 9 months ago

Likewise I noticed that Konsole was version 23.08. I've just submitted a PR (https://github.com/jquast/ucs-detect/pull/14) to update it to 25.08.

aidenn0• 9 months ago

They accept PRs on the ucs-detect project for updated test results.

scuderiaseb• 9 months ago

Nothing even mentioned on WezTerm really?

embedding-shape4• 9 months ago

It's in the results, even if not mentioned in the blogpost: https://ucs-detect.readthedocs.io/results.html#general-tabul...

greggh• 9 months ago

People still use WezTerm when we have Kitty and Ghostty? Can you explain why? I'm actually interested to know what would make someone make that choice.

alwillis6• 9 months ago

People still use WezTerm when we have Kitty and Ghostty?

Very customizable and extensible using Lua. Extensive documentation, native ssh support and built-in multiplexing.

pneumic• 9 months ago

Wezterm is actually programmable. I am looking to drop Kitty as it intentionally offers minimal tmux support and the text rendering options that made it superior for me are being deprecated.

Until Ghostty offers the scriptability found in wezterm and kitty (e.g., hit a keybind, spawn a new terminal and execute a font picker script), I am trying out wezterm, which is pretty great, but renders fonts too thin by default. I stare at this thing eight hours a day so text rendering is super important.

sigmonsays• 9 months ago

I prefer WezTerm over ghosttty and kitty.

I prefer it's UI and level of customization.

Ghostty animations run like crap for me on linux (not sure why).

bbkane2• 9 months ago

Folks have responded about WezTerm's programmability being the reason they like it, but if you don't mind I'd like to flip the question around: why do you prefer Kitty or Ghostty to WezTerm?

qart• 9 months ago

I have them all installed, but I use WezTerm most often because it is fastest to give me a window when I hit the assigned shortcut key. Ghostty is a hair slower. Kitty takes 2-3 seconds. I keep launching terminals pretty frequently, so this matters to me a lot. The only other feature that it must have is truecolor.

rashil2000• 9 months ago

I love WezTerm! Recently switched from iTerm2 and programmed the hell out of it: https://rashil2000.me/blogs/tune-wezterm.

It has a very extensive Lua API.

skerit• 9 months ago

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.

didibus• 9 months ago

I think it's because Kitty and Ghostty are the newest terminals, so they came up with new modern options and solutions.

embedding-shape4• 9 months ago

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, so I wouldn't be surprised not every terminal is rushing to implement it.

Or I completely misunderstand what you're talking about.

porridgeraisin• 9 months ago

Yes, pictures. It's quite useful. Opening images on remotes for one. Viewing plots arbitrary python scripts create for another.

Off the top of my head.

alwillis6• 9 months ago

I’ve found it useful, when paired with a terminal file manager, to preview graphics in the terminal.

the_gipsy2• 9 months ago

The alacritty maintainers reject any image protocols as unnecessary. I am fond of images in terminals, but I gotta say that I respect their decision, very good call. Not every terminal emulator should do the same.

ziotom78• 9 months ago

I run Kitty and use this feature regularly. Most of the time, I rely on it within Yazi [1], a TUI file manager, but I can also display plots within the Julia REPL, thanks to the KittyTerminalImages.jl package [2]. It's even more crucial when I'm navigating a remote directory and need to check an image file, as I usually have timg [3] installed on those servers. Once you discover how valuable this is, it becomes a permanent part of your workflow.

[1] https://yazi-rs.github.io/

[2] https://github.com/simonschoelly/KittyTerminalImages.jl

[3] https://github.com/hzeller/timg

xp84• 9 months ago

I have to say, (caveat, I have not tried any of these yet) that I am intrigued by all these features like graphics being added to terminals. It feel like exploring an alternate timeline 1990s where the GUI “lost” — of course in the absence of a successful Windows and Macintosh, terminals would have naturally gained these graphical abilities 30 years ago.

trenchpilgrim2• 9 months ago

Viewing an image in a terminal can be really handy for debugging ML systems that use images or bitmaps. You can also paste images directly into claude code as context.

Once while working on a daemon that did both ML and DSP on live audio I added the ability to play sounds and display spectrographs of in-memory audio data at various points of the internal pipeline to debug an issue that would have been difficult otherwise. Way quicker than dumping WAV files to view externally.

setopt• 9 months ago

It’s pretty nice to ssh into a remote host and plot some data there without needing either X forwarding, or dumping to files and rsync’ing, or similar workarounds.

mikkupikku• 9 months ago

Images in a terminal emulator is neat for stuff like `ranger`

lloeki• 9 months ago

I'm not particularly fond of displaying images on the terminal in ways that would resemble a GUI.

That said, augmenting a shell-based workflow with tidbits such as this had me sold:

https://xcancel.com/thingskatedid/status/1316074032379248640...

https://xcancel.com/thingskatedid/status/1316075850580652032...

To achieve that, either Sixel or Kitty protocol is fine. IIRC Sixel works over SSH without any fuss, dunno about Kitty.

bee_rider• 9 months ago

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

kyawzazaw• 9 months ago

Curious, what do you do with this?

mechanicum• 9 months ago

More than two, e.g. there’s also the Inline Images Protocol supported by iTerm2 and WezTerm.

Kovid documented his rationale at some length here: https://github.com/kovidgoyal/kitty/issues/33

zadjii3• 9 months ago

FWIW The definitive thread on "images in terminals" is probably found in these threads:

https://gitlab.freedesktop.org/terminal-wg/specifications/-/...

there's lengthy discussion from just about everyone at this point in those threads, about why images in terminals is Hard

IshKebab6• 9 months ago

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

I think probably that requires a full fat video codec like H.264 to work well though. Or maybe RDP?

Probably too many GUI naysayers and "What's wrong with remote X?" for this to ever happen though.

duskwuff2• 9 months ago

At that point you're really better off using some other remoting protocol instead of trying to tunnel it all over a terminal session. There's nothing left of the original terminal.

anthk7• 9 months ago

drawterm under Unix clients and 9front cpu connections; but that's Unix Philosphy 2.0.

zokier• 9 months ago

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.

toast02• 9 months ago

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.

alberth• 9 months ago

mitchellh says no plan to support Sixel:

https://xcancel.com/mitchellh/status/1985432954089455856#m

electroglyph3• 9 months ago

to be fair, pretty much anything would be better than sixels

shiomiru• 9 months ago

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".

forgotpwd16• 9 months ago

why is it only used

Sixel has existed for 40y, Kitty protocol originated and initially made for a single project (Kitty) few years ago.

why we have 2 competing protocols

Well, iTerm2 also got its own image protocol (predating Kitty's but basic, only meant to show images rather graphics in general) that has been adopted by few other projects. Terminology also got something on its own, and urxvt can show images by setting the background image.

bartvk• 9 months ago

The terminal that comes with macOS version ends on the 29th place in the results.

sccxy• 9 months ago

and terminal that comes with Windows is on the 4th place.

alwillis6• 9 months ago

Yeah… Apple hasn't done much with Terminal.app since they inherited it from NeXT back in the late '90s.

FWIW, it did get Powerline support and 24-bit color in macOS 26.

krackers• 9 months ago

In 10.10 they added scroll emulation and inline find.

doug_durham• 9 months ago

Yeah, I don't understand. I spend my day in the macOS terminal app and the thought "Hey I'd like a better terminal" has never occurred to me.

toast02• 9 months ago

Maybe it's better now, but when I started my time on OSX, the built in terminal defaulted to "unlimited" scrollback, so if you were used to tailing giant log files, it would beachball pretty quick. I spent the rest of my time using iterm2 instead; it defaulted to a sensible scrollback length; and at some point it added a progress bar when you made a giant paste.

cosmic_cheese4• 9 months ago

Perhaps my needs are too pedestrian, but I don't believe I've ever needed anything more than what the macOS Terminal app is capable of. I've tried the vaunted iTerm2 and Ghostty among others but they never stuck.

sitzkrieg• 9 months ago

the ranking weighed fluffy things i do not want indeed

Asooka• 9 months ago

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.

sph2• 9 months ago

2052: the whole of computing is VT100-compatible Javascript CLI applications running on a Javascript port of the Linux kernel, within a tab of Chromium.

This is the actual end game of the worse is better philosophy.

anthk7• 9 months ago

It's 9front actually. VT100 it's killed except for legacy plaforms, it's seen like CP/M and Altair emulators where looked upon 1995-2000.

9front's libc with a minimal desktop based on a tweaked rio(1) and a taskbar plus a really simple file manager won. People god fed up of FX' and bells and whistles everywhere. A minimal RTF editor with simple options plus a simple spreadsheet with rc/awk support does things much faster. Oh, and, of course, you can damn bind/import devices (video cards, network cards, whole networks) from anywhere to anywhere with IPV6 and quantum networks.

Old GNU/Linuxen, OpenBSD et all are just virtualized at crazy speeds under photonic CPU's.

There's no SSH, just rcpu and quantum-secured factotum(1). Photonic GPU's and neural network devices just boot 9front themselves too, with zero delay. Forget VPN's, too. These are obsolete too.

temp0826• 9 months ago

There is an in-terminal wayland compositor (or two?) out there, fwiw.

Edit- one example https://github.com/mmulet/term.everything

dmd2• 9 months ago

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

alwillis6• 9 months ago

Yes! Hoping I can get Neomutt to render HTML email without resorting to launching a browser.

Since URLs are clickable in iTerm, you have the option to view a webpage in the terminal.

AceJohnny2• 9 months ago

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

mfld• 9 months ago

While there's vscode console, I think that bare Xterm.js would be a nice addition to the list.

iammrpayments• 9 months ago

I would use neovide over anything else if they supported macos tabs. It’s the termianl with the best font readability for me.

duskwuff2• 9 months ago

Disappointingly, the native UI for tabbed windows on macOS changed drastically in Tahoe (26.0). I really dislike the new tabs - they're significantly larger, and much harder to integrate into a small window like a terminal.

acuozzo• 9 months ago

There isn't a single mention of vttest results.

altairprime8• 9 months ago

What features tested by vttest, that aren’t measured by ucs-detect, would you want to see added to ucs-detect?

alkh2• 9 months ago

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!

hnlmorg7• 9 months ago

I thought built in theme pickers were the norm…?

alkh2• 9 months ago

Lol, mb, but I don't believe that's the case for Alacritty. As for the Apple Terminal, it is not great

alwillis6• 9 months ago

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

mort96• 9 months ago

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.)

nusaru• 9 months ago

Relevant GitHub issue: https://github.com/ghostty-org/ghostty/issues/189

klooney• 9 months ago

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

chrysoprace3• 9 months ago

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.

Imustaskforhelp3• 9 months ago

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?)

seanw444• 9 months ago

Same here. Any replacement I moved to needed to have content centering, where the margin around the cells is equal in both dimensions when the cells don't fit perfectly into the window. Kinda crazy that it's not a feature in a lot of terminals I checked over the years. I wouldn't even consider myself OCD, but it drove me nuts until I found a terminal that let me do it.

OberstKrueger• 9 months ago

The first time I went through the theme picker, I was tickled to see a theme I had made years ago included. Realized later it was due to it including all of the themes from iTerm2 Color Schemes automatically.

It made for a more fun first experience with a terminal emulator than I expected to have.

bsimpson• 9 months ago

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.)

jeffbee2• 9 months ago

So, don't type your password into your terminal emulator? In many situations (ssh and suchlike) you can use another means of unlocking your credentials.

tristan9573• 9 months ago

If Konsole suits your needs, there is no reason to move to Ghostty. You may find better performance or access to more terminal features, but if those don't move the needle for you, then it doesn't matter. Konsole is well integrated in to KDE.

zadjii3• 9 months ago

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?

gschizas• 9 months ago

In the test, Windows Terminal (weirdly written as "terminal.exe") comes up as #4 in the scoring table.

As to the "love" question, I still watch this video from time to time: https://www.youtube.com/watch?v=8gw0rXPMMPE :)

EDIT: I love the easter egg with the names of the developers across the Windows timeline :)

epolanski3• 9 months ago

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

But I'm no power user.

bigstrat20035• 9 months ago

I would argue that anyone who uses the terminal enough to have opinions on which one they like best is very much a power user.

jscyc• 9 months ago

It's what I most miss from using windows. It handles tabs, theming and renaming of windows so well. Being able to tell at a glance what each window is connected to, it's purpose etc is very handy for me.

jeffbee2• 9 months ago

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.

alwillis6• 9 months ago

It would amazing if iTerm used the Ghostty library (libghostty) for the core terminal functionality; then the developer could focus on UI/UX. iTerm has tons of useful features, but a lot of them are buried in the UI.

electroglyph3• 9 months ago

no xterm.js? it's a very good cross-platform terminal emulator

altairprime8• 9 months ago

That seems fixable with a pull request to ucs-detect, if one hasn’t already been made.

electroglyph3• 9 months ago

good call, you're right

christophilus• 9 months ago

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

ac29• 9 months ago

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.

tristan9573• 9 months ago

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

colordrops3• 9 months ago

Foot is the best. Love ctrl-shift-o to open up links

RVuRnvbM2e• 9 months ago

I'm quite confused why this article tests foot v1.16.2, which is two years old at this point. The latest version is 1.25.0.

By contrast, the tested version of ghostty v1.2.3 is two weeks old.

aorth• 9 months ago

Good point. I just submitted a pull request with new data for foot 1.25.0 https://github.com/jquast/ucs-detect/pull/17. The test suite is really easy to run (and fast, foot rocks!).

bdunks• 9 months ago

I agree. I started using Foot based on a recommendation from the notcurses library author, who has deep expertise in terminal emulation and collaborates with maintainers.

A tip for new users: The default theme is a bit harsh. I was able to port my Alacritty theme and other config by feeding the config file to an LLM (along with the Foot documentation). It generated a configuration that was 80-90% correct and only required about five minutes of manual fixes.

The result is now visually identical to my Alacritty setup, but Foot feels faster.

enriquto• 9 months ago

The table seems wrong. Xterm supports sixels.

altairprime8• 9 months ago

You can fix that with a pull request to ucs-detect; for example: https://news.ycombinator.com/item?id=45801452

the_gipsy2• 9 months ago

Only if run with `-ti 340` argument. So in general, it's not there.

omoikane• 9 months ago

Same for mintty.

I tried `echo "\e[c"` (send device attributes) on mintty 2.8.1 just now and got "4" back ("VT132 with Advanced Video and Graphics").

cb3213• 9 months ago

`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.

imiric2• 9 months ago

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

cb3213• 9 months ago

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.

topaz02• 9 months ago

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.

ubercow13• 9 months ago

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 insist on printing emojis in their output

hnlmorg7• 9 months ago

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 terminal pretty. But emojis in software feels like juvenile - like signing a formal letter with your gaming handle.

topaz02• 9 months ago

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 lose points is mostly in pretty complicated cases that are far from what terminals were originally designed for. Also I have never encountered a command line tool that prints emoji -- and if I did, I would be annoyed.

bigstrat20035• 9 months ago

Literally none of those is a situation I've ever encountered. I don't think it's as hard to avoid as you think.

anthk7• 9 months ago

Accented letters are easy under GNU/Linux or OBSD under X. Just launch:

    setxkbmap -us option ctrl:swapcaps -option compose:rwin

The first switch switches ctrl with caps lock (it helps your hands) and the last one maps the right Windows key (you can use menu key from laptop too with compose:menu) so you just type [ ' ] [ a ] and you'll get an á char.

imiric2• 9 months ago

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.

joouha• 9 months ago

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.

loph• 9 months ago

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.)

dgl3• 9 months ago

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

altairprime8• 9 months ago

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

unleaded3• 9 months ago

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

tmtvl3• 9 months ago

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>.

unleaded3• 9 months ago

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.

dgl3• 9 months ago

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.

p_l3• 9 months ago

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

mmastrac• 9 months ago

I've started working on a VT420 emulator which is about 70% complete: https://github.com/mmastrac/blaze

LukeShu• 9 months ago

You can do the same thing with a vt220.

Can you? The last I looked at it (a year or two ago), the vt220 in MAME was just the beginning skeleton of an implementation, and it doesn't seem to have been touched much since then. A shame, because AFAIK no "terminal emulator" implements vt220-style sixels (which are different than than the widely-implemented vt4xx-style sixels).

unleaded3• 9 months ago

I checked and it was actually the vt240. That one works.

kevin_thibedeau4• 9 months ago

This also looks closer to the original with some shaders to add pincushion distortion and Gaussian scanlines.

anthk7• 9 months ago

Forget MAME; I'd love a forked project for this minus the shaders for old machines. Where you just get the terminal emulation with a good TTF font and that's it. There are similar projects for the Altair 8800 where they scrapped their code from SIMH (now I prefer simh-classic) to just emulate a CP/M 2.2 Altair machine and that's it, because these people don't need to emulate PDP10's with ITS, old BSD's, current VAX NetBSD releases or the rest of the DEC machines...

blueflow2• 9 months ago

They do emulate a terminal, not just the kind of emulation you have in mind. "Wine is not an emulator" again.

sho_hn• 9 months ago

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.

yokljo• 9 months ago

Agreed. It's nice to be able to just use the provided terminal when running KDE. It's very customisable and runs plenty fast. I also love being able to right click on Dolphin and tell it to open Konsole in the current folder. Also, I leave infinite scroll back turned on in Konsole and it works really well, swapping out to a file as it gets too much scroll back. Nothing worse than getting errors that I can't read because the terminal discarded them. I have Ctrl+Shift+X bound to clear everything, which I use before running just about any operation.

jcgl• 9 months ago

I also love being able to right click on Dolphin and tell it to open Konsole in the current folder.

This is a KDE thing; it'll open in whatever terminal you've got configured in Default Applications.

whateveracct• 9 months ago

Konsole Just Works

TiredOfLife• 9 months ago

Unfortunately Konsole has this feature that each time you switch tabs the maximized window shrinks by a couple of pixels (at least on Steam Deck)

j1elo3• 9 months ago

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!

stefanha• 9 months ago

In Linux (Wayland) you can copy text from the terminal without pressing Ctrl+C at all. Just select the text. To paste it in another Window, press the middle mouse button.

This is called the Primary Selection and is separate from the Clipboard (Ctrl+C/Ctrl+V). IMO the Primary Selection is more convenient than the Clipboard.

j1elo3• 9 months ago

Yeah I know. I missed this for the first couple days, but didn't take much before forgetting it after the change to Windows. (anyway I keep using Linux at home)

DaSHacka• 9 months ago

Isn't this an X11-ism? I dont believe this is Wayland-specific

lelandbatey• 9 months ago

This is also a thing in X, not only Wayland.

pmontra3• 9 months ago

That's an X11 thing that Wayland had to reimplement because it's so convenient. The problem is when pasting into the terminal something that another program copied into the clipboard. That's ctrl-shift-c.

I thought about remapping copy and paste to their own keys, possibly a single one. Maybe on the number pad, which I never use. Or remapping ctrl-c.

bluebarbet• 9 months ago

middle mouse button

Speaking for myself (although I suspect many others), I haven't used a mouse in well over a decade. To be clear, I am in the terminal all the time. So this is not a universal solution.

dzaima• 9 months ago

But that doesn't go into clipboard history. And severely restricts what you can do between copying and pasting in general (very importantly makes it a pain to do replace (i.e. select+(implicit-delete+)paste)) as any intermediate selection before pasting destroys your Primary Selection. And if you realize you did that, recopying takes manually reselecting the text, or the otherwise-never-used ctrl+insert to recopy, instead of just repeating the same old ctrl+c as you always do with the clipboard in any sane application.

Of course still a nice option (esp. in terminals where the proper copy/paste are nerfed and selecting for editing is annoyingly not a thing), but far from a replacement for the proper clipboard.

bytehowl• 9 months ago

How do you paste the selected text if you want to replace a text selection in the other window?

cosmic_cheese4• 9 months ago

Mac terminals yield a similar benefit, with the systemwide copy/paste Cmd+C/V not overlapping with Ctrl+C/V.

Being used to that, Linux terminals become rather annoying. Yes there's other ways under Linux, but they don't have 25+ years of muscle memory associated with them, and so when the key shortcuts don't work as expected it's like nails on a chalkboard.

jack_pp2• 9 months ago

Heh, shortcut muscle memory is the reason I returned my Mac mini one week after trying it. I sure am not gonna remap my brain for apple after 20 years of Linux and windows.

taftster2• 9 months ago

I really do like Cmd key usage for any terminal in Mac. The ability to send Ctrl+C differently than Cmd+C in a Mac is joyous.

However, for most all other applications in Mac, I dislike the Mac command key. Especially in IDEs like vscode, etc.

And I really hate that the actual Ctrl key on a Mac is in the wrong place, having swapped places with Fn. It's like the first thing I have to remember to do on each Mac setup, swap those two keys.

Because I'm toggling between mac/windows/linux all day long, my poor muscle memory is always confused. And it would be nice if this could be unified. Unfortunately, I'm guessing it would have to be solved more by Apple than by Microsoft or Linux.

kps• 9 months ago

There are *nix terminals that will let you bind shortcuts that don't conflict with terminal control keys. Konsole and KDE stuff in general will let you set Mac-style bindings (with some config effort), though I personally use mlterm.

sunshowers• 9 months ago

The tradeoff here is that Macs don't have a system key that most applications don't interpret in some way. On Windows and Linux, system key shortcuts are much easier to set up.

jwnin• 9 months ago

windows terminal is awesome and i wish it shipped with windows by default instead of having to go to the store and install it. everyone who uses it has only good things to say, and it is updated regularly by Microsoft.

Iwan-Zotow• 9 months ago

It is default in w11 25h2

DHowett• 9 months ago

It comes with Windows, and has since 2022! Alas, if you mean Windows 10 then you can use some DISM magic to add it to an install image.

zadjii3• 9 months ago

It's shipped with Windows since Windows 11. Updates come via the Store (since that's a lot faster than OS updates), but it's definitely preinstalled these days

ajross3• 9 months ago

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?

nitinreddy88• 9 months ago

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

ghosty1413• 9 months ago

I mean ctrl+c/v is just muscle memory, obviously there are tons of other way but ctrl+c/v are just the default and the one everyone knows.

h3x4d3c42• 9 months ago

Not sure if this was available from the beginning, but Ghostty has the ability to do exactly that with what they call "performable" keybindings

<https://ghostty.org/docs/config/keybind#performable:>

mongol3• 9 months ago

Hope Kovid Goyal gets inspired by this

ghosty1413• 9 months ago

Oh wow, I'm already using ghostty and didn't know about this. It works great, thanks!

mongol3• 9 months ago

This is genious. It is one of the most annoying things remaining in the Linux desktop and I often press Shift-Ctrl-C in the browser by mistake, opening up the dev tools in the process, while intending to copy.

Are there any legitimate reasons to send Ctrl-C except to abort, that this could interfer with?

thayne• 9 months ago

FWIW, in zsh, and probably other terminals, you can bind ctrl+v to be paste. Many terminal emulators also allow you to bind ctrl+v to paste, although that may interfere with applications that use ctrl-v for something else.

Kitty has a copy_or_interrupt action that behaves like you describe. Although, I think it would interfere with apps where ctrl-c is handled specially.

Edit: kitty also has a copy_or_noop action that passes through the ctrl+c if there is no selection.

Yizahi• 9 months ago

I really wish PC manufacturers didn't kill Insert button. It worked just fine for decades with Ctrl-Ins/Shift-Ins, and in every terminal I've tried. But now the button is missing more and more often (thanks HP, I appreciate useless call and share buttons in its place, which don't work anywhere), and fixes need to be invented for a solved problem.

indigodaddy• 9 months ago

Yeah shift-ins really is the way

teo_zero• 9 months ago

It doesn't look so convenient to me. If Ctrl+v is bound to paste, how do you insert a verbatim character in the shell? How do you start a block visual selection in Vim? How do you scroll down in emacs?

blueflow2• 9 months ago

You don't but you don't notice if you never did anything like that. Half of the keybinds listed by 'stty -a' are a mystery to mankind.

throw0101c• 9 months ago

If Ctrl+v is bound to paste, how do you insert a verbatim character in the shell?

For those unaware:

Unix interactive terminals use Control-V to mean "the next character should be treated literally" (the mnemonic here is "V is for verbatim"). This allows a user to insert a literal Control-C or Control-H or similar control characters that would otherwise be handled by the terminal. This behavior was copied by text editors like vi and Unix shells like bash and tcsh, which offer text editing on the command line.[3]

* https://en.wikipedia.org/wiki/Control-V

j1elo3• 9 months ago

Seems to me a reasonable concern but I'd bet it's only for a minority of users... so perfect candidate to have implemented, but given as a disabled by default setting.

co_dh• 9 months ago

I have to warning everyone: Windows terminal with true color , possibly with tmux, is very slow. There is a half second delay from key press to response. I am in a vdi. Your miles varies.

ciberado• 9 months ago

This doesn't correspond to my experience. The terminal is not faster than light, but good enough for my requirements, and I use it both locally and through VNC. May it be a problem with your VDI setup?

usrbinbash2• 9 months ago

So convenient!

Running in tmux, marking anything on my terminal immediately puts it into the tmux buffer, without me having to click anything on the keyboard. Pressing middle-mouse pastes it.

THAT is convenience.

rovingeye• 9 months ago

I have that turned on in Windows Terminal but still use ctrl+c because it's how all other software works

ur-whale3• 9 months ago

immediately puts it into the tmux buffer

Can you paste in a non-terminal app though (like a web browser) ?

biehl• 9 months ago

That sounds like an awesome concept. However, I'm restarting Linux usage after 10 years on Mac, and I am surprised on how much less annoying the Shift-ctrl-v is compared to what I expected.

fithisux• 9 months ago

Yori is also a very capable replacement.

ctippett2• 9 months ago

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?

kartoffelmos• 9 months ago

vscode terminal came in at number 32.

https://ucs-detect.readthedocs.io/sw_results/vscodeterminal....

ctippett2• 9 months ago

I missed that one!

uvaursi• 9 months ago

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?

shirro• 9 months ago

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.

kevin_thibedeau4• 9 months ago

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.

charcircuit• 9 months ago

The terminal emulator knows what font is being used so it should be possible to predict it.

lifthrasiir• 9 months ago

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.

anthk7• 9 months ago

It does it fine with GNU Unifont and raw XTerm and others. I just had issues with RXVT and clones.

musicale• 9 months ago

I'd like to see the key-to-pixel latency speed championship.

eschatology• 9 months ago

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?

bardsore• 9 months ago

How fast my terminal can print 10000 lines is pretty far down the list of requirements I have, who cares as long as it is fast enough? To me it is as irrelevant as who has the best unicode support.

ivanjermakov• 9 months ago

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...

Piraty• 9 months ago

a look at terminal emulators

https://lwn.net/Articles/749992/

https://lwn.net/Articles/751763/

dmaa• 9 months ago

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.

krautburglar• 9 months ago

it is also a lot easier on the battery than iterm2

p_l3• 9 months ago

Interesting that xterm is written off as not supporting sixel, when in actuality it supports both full SIXEL and ReGIS and Tek 4010, with 24bit colour IIRC.

It's just not enabled by default.

Joker_vD• 9 months ago

Kitty and Ghostty are the only terminals that correctly support Variation Selector 15,

Really? Because IIRC they "support" it by treating the preceding emoji character as being Narrow instead of Wide. This is completely unsupported by anything in the Unicode standards: the codepoint sequences that affect the East Asian Width of their first codepoints are explicitly enumerated, and none of them have emojis and/or VS-15 in it. So no, it's not "correctly" supported. Emojis are Wide (terminal width 2) with or without VS-15/VS-16, and if fonts have textual renditions of them that are only 1 cell wide, well, that's the fonts' problems, just as fonts that have e.g. glyphs for Playing Cards block with visible width of 1.5 (I am looking at you, Google Noto) are wrong too.

j4_james• 9 months ago

Agreed. The only thing that VS-15 is supposed to do is give the emoji a "text presentation", which the spec suggests as "black & white". And every example they show of a text presentation is exactly the same width as the emoji presentation.

Changing a character's width from wide to narrow after it has already been output is fraught with problems for a terminal. Imagine trying to write a "narrow" text presentation emoji in the bottom right corner of the screen. You'd think it should fit, but the emoji is received before the VS-15 selector, and that doesn't fit, so the terminal is forced to wrap the text, triggering a scroll of the entire page. By the time the VS-15 arrives, there's no way to undo all of that.

And for another example, try using IRM (insert replace mode) to insert a text presentation emoji in the middle of some existing text. If it was really narrow, you'd expect it to insert enough space for just one character, but it actually inserts two spaces, only occupying one of them, and then leaving an unexpected gap. And the more of these "narrow" characters you insert, the bigger the gap becomes.

VS-16 changing a text presentation character from narrow to wide doesn't share these problems. And that behaviour is supported by the spec text, which says that emoji should generally have a square aspect ratio. And at one time the East Asian Width spec specifically mentioned VS-16 making narrow characters wide (but said nothing about VS-15 making wide characters narrow).

UltraSane• 9 months ago

Why are we still emulating dumb terminals in 2025?

childintime• 9 months ago

These terminals properly handle single + double width fonts. But the same thing could work with single + half width fonts, so i,j,l,:,!,.,' and space would fit in half the width. Does anyone know of such a font? I searched but couldn't find any bi-spaced font with full/half width cells.

It would not only fit more text on a line, while (probably) also being nearly as pleasing as a proportional font, but it would also still perfectly align indents. I think it could be a great markdown font.

akho• 8 months ago

Indents align perfectly in any font. Alignment in columns (like what go fmt likes) is problematic.

State of Terminal Emulators in 2025: The Errant Champions

Related Stories