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.
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...
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).
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
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!
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.
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.
Yes, but specifically in the context of Terminals (as discussed in the original article), it's really convenient to be able send Ctrl-C (break) differently than Cmd-C (copy).
So yes keyboard remapping is an option. But there's just differences you can't remap because of the extra meta keys on Mac (and I guess on Windows too, with the Copilot or Start keys in play).
> it's really convenient to be able send Ctrl-C (break) differently than Cmd-C (copy)
Right, and even on Linux you can do it by using the four-fifths forgotten CUA shortcut Ctrl-Insert for copy (and Shift-Insert for paste.) Although I'll admit to using Ctrl-Shift-C/V most of the time.
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.
On all my machines I remap Caps Lock to Control, and since I still use Control from time to time under macOS, I have muscle memory for it, and so switching between Control/Command dominance is low friction.
Control in its typical position however drives me crazy.
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.
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.
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)
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?
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.
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.
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.
You can cut/paste within your editor just fine. The subject at hand is window-system level clipboard/selection interaction, and in particular the presence of standard key bindings for them in various environments. While some terminal and editor apps do have keyboard bindings that interact with the OS clipboard, none are standard.
Basically, yeah: you had to use the mouse to select it in the first place. Using the mouse to paste it is easier, not harder.
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.
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?
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.
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.
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.
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.
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 are a ton of people who _immediately_ open tmux/zellij/etc. when they're doing anything in the terminal. This means you use its backscroll and search feature, and you wouldn't notice.
@mitchellh seems to rely on the Ghostty feature to dump scrollback to a file, and edit/search over that.
I found it a bit too inconvenient when using remote systems frequently, though. (If I'm missing a trick, I'd love to use Ghostty! But I'm just not a fan of multiplexers.)
Honestly, I had never even heard of it before this very thread. It doesn't seem all that useful to me, but I don't truthfully know how much or how little I would use it in practice.
> To be completely clear, it’s not on the “IMMEDIATE” roadmap (as noted in the prior comment). It’s absolutely on the roadmap and I even already started some it in a branch. But as a passion project, we prioritize working on whatever we want and this isn’t currently the priority. It’s high on the list but not like.. next release (“immediate”) priority at the time of this comment.
I mean I can respect that, personally it isn't as a big of deal with me so I use ghostty on my mac but I would still think that I would advocate ghostty only after disclosing this to anyone to be really honest.
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.
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.
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.
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 on omarchy but I don't like omarchy)
Is there actually a way to fix this skill issue, like I want something so simple in start that I just run it and forget and still get decent amount of benefits?
tmux fits my personal use case better so I'll tell you why I use tmux and then if that resonates with you, then you might get value from that as well.
- It's generally bundled on most distros, or available for install in most default repositories.
- tmux sessions are available over ssh, so if I can continue where I left off over ssh (this is probably my main use case).
- I can full screen my terminal instead of having multiple terminals, and split in tmux. I usually split vim buffers, but then keep a terminal split beside it or in another tmux window.
- It's keyboard-driven, and universal across different window managers. Even if I switch from MacOS to Windows or to an X11 distro, tmux will still have the same keybinds using the same configuration language. I can also use vim keys to navigate the scrollback history.
- Its config language is simple enough for the modifications I personally need. I haven't felt that I need to learn the syntax beyond the basics.
- Knowing tmux is also a helpful skill for managing servers, which I do from time to time (my raspberry pi is still running a tmux session from when I last rebooted it).
Apple Terminal is a lot like Internet Explorer in the 00s: for power users it’s only purpose is an interface to install something else which doesn’t suck.
As a decrepit old {COMMO} power user, anything that doesn’t give me fully integrated scripting with expect/switch/dialog and a popup script editor, honestly hasn’t been worth investing in further. So I’ve been on Linux console, Putty, and macOS Terminal ever since.
My terminal.app color scheme uses P3 colors on 7% gray rather than the usual sRGB colors so that I can use an OKLCH equidistant palette, and I make extensive use of shift-cmd-up to select and copy “the previous command’s output”. I considered switching for 24-bit color but ultimately I prefer not having to learn a new “rudimentary” app that’s deficient versus my nostalgia just like all the others, and it drastically reduces my stress level when working on other people’s devices that I am proficient in working with an OEM environment.
I occasionally use tabs but for the most part I prefer windows, so that I can drag them around and over/underlapped with other work I’m doing in my GUI. Not a big fan of screen and tmux except as their limited value to me in mitigating ssh disconnects when that’s a concern.
Perhaps your definition of power user is limited to uses aligned with your own?
I think of it every time I see 'ansible' come up, because the ability to create and run what everyone calls 'playbooks' now should have beeen integrated into the terminal like it was back in the 80s over dialup. I'm all for being able to git commit the resulting script (they’re just text files!) but being able to launch a playbook and halt it and repair it and resume was, like.
I used IE back in the 00s (up until Chrome came out), and I certainly was a power user. I liked it just fine. I think that it's a matter of personal preference rather than something sucking (or not).
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?
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.
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?
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.
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.)
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?
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).
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.
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.
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.
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.
> 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.
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.
Definitely. I use KittyTerminalImages.jl often, and also the image.nvim plugin for embedding images into a Markdown or other buffer in Neovim: https://github.com/3rd/image.nvim
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.
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.
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.
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.
I can confirm that I just do it over ssh fine all the time -- gnuplot, img2sixel as an "image-cat", etc. (`st` with patches to add sixel support as discussed in various places in these comments.)
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.
> 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.
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.
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.
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.
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 enough to be worth the bother, then we'd all have been using them all along and there wouldn't be posts like this.
It's not a case of there's this awesome idea that just for some reason no one knows about. No, it's just not that awesome of an idea. It's not harmful so it doesn't bother me that most xterms support tektronix graphics, it's just a gimmick of no real value. It's a solution to no problem.
Don't believe me? When was the last time you used passthrough printing? Or saw it being used even in some place where they do actually need to print? The terminals all still support it. It's just a thing that you don't need to do in-band in a tty, and today there is no reason to bother doing it that way even though you could. It's not better and does not solve a problem.
I have yet to use it though because Wayland still doesn't work properly for me (it doesn't restore the desktop properly after sleep) so I'm still on X11... without compositing... because KWin's compositor causes random freezes.
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.
- 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
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.
> 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.
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.)
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.
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.
`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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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):
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.
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...
> 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).
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
This also looks closer to the original with some shaders to add pincushion distortion and Gaussian scanlines.
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!
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.
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.
It's easy and reasonably quick to set up key remapping (via Karabiner).
Yes, but specifically in the context of Terminals (as discussed in the original article), it's really convenient to be able send Ctrl-C (break) differently than Cmd-C (copy).
So yes keyboard remapping is an option. But there's just differences you can't remap because of the extra meta keys on Mac (and I guess on Windows too, with the Copilot or Start keys in play).
> it's really convenient to be able send Ctrl-C (break) differently than Cmd-C (copy)
Right, and even on Linux you can do it by using the four-fifths forgotten CUA shortcut Ctrl-Insert for copy (and Shift-Insert for paste.) Although I'll admit to using Ctrl-Shift-C/V most of the time.
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.
On all my machines I remap Caps Lock to Control, and since I still use Control from time to time under macOS, I have muscle memory for it, and so switching between Control/Command dominance is low friction.
Control in its typical position however drives me crazy.
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.
Isn't this an X11-ism? I dont believe this is Wayland-specific
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.
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)
This is also a thing in X, not only Wayland.
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?
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:>
Hope Kovid Goyal gets inspired by this
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.
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.
It is default in w11 25h2
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.
> 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.
You can cut/paste within your editor just fine. The subject at hand is window-system level clipboard/selection interaction, and in particular the presence of standard key bindings for them in various environments. While some terminal and editor apps do have keyboard bindings that interact with the OS clipboard, none are standard.
Basically, yeah: you had to use the mouse to select it in the first place. Using the mouse to paste it is easier, not harder.
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...
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?
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.
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.
> 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.
Konsole Just Works
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>.
a look at terminal emulators
https://lwn.net/Articles/749992/
https://lwn.net/Articles/751763/
I'd like to see the key-to-pixel latency speed championship.
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.
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.
The terminal emulator knows what font is being used so it should be possible to predict it.
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.
There are a ton of people who _immediately_ open tmux/zellij/etc. when they're doing anything in the terminal. This means you use its backscroll and search feature, and you wouldn't notice.
@mitchellh seems to rely on the Ghostty feature to dump scrollback to a file, and edit/search over that.
I found it a bit too inconvenient when using remote systems frequently, though. (If I'm missing a trick, I'd love to use Ghostty! But I'm just not a fan of multiplexers.)
I’ve never used scrollback search, and it was a discovery for me that there’s a contingent that are very vocal in their demands for scrollback search.
I can see why someone would feel attached to this feature though.
Mostly I’m looking forward to seeing it implemented so I can stop reading complaints about this being missing in every thread about ghostty!
I wish they didn’t lock the GitHub issue so that we could see how many thousands more reactions it would get.
Honestly, I had never even heard of it before this very thread. It doesn't seem all that useful to me, but I don't truthfully know how much or how little I would use it in practice.
Relevant GitHub issue: https://github.com/ghostty-org/ghostty/issues/189
> To be completely clear, it’s not on the “IMMEDIATE” roadmap (as noted in the prior comment). It’s absolutely on the roadmap and I even already started some it in a branch. But as a passion project, we prioritize working on whatever we want and this isn’t currently the priority. It’s high on the list but not like.. next release (“immediate”) priority at the time of this comment.
I mean I can respect that, personally it isn't as a big of deal with me so I use ghostty on my mac but I would still think that I would advocate ghostty only after disclosing this to anyone to be really honest.
It's planned for 1.3 in March https://ghostty.org/docs/install/release-notes/1-2-0#roadmap
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.
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.
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.
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 on omarchy but I don't like omarchy)
Is there actually a way to fix this skill issue, like I want something so simple in start that I just run it and forget and still get decent amount of benefits?
tmux fits my personal use case better so I'll tell you why I use tmux and then if that resonates with you, then you might get value from that as well.
- It's generally bundled on most distros, or available for install in most default repositories.
- tmux sessions are available over ssh, so if I can continue where I left off over ssh (this is probably my main use case).
- I can full screen my terminal instead of having multiple terminals, and split in tmux. I usually split vim buffers, but then keep a terminal split beside it or in another tmux window.
- It's keyboard-driven, and universal across different window managers. Even if I switch from MacOS to Windows or to an X11 distro, tmux will still have the same keybinds using the same configuration language. I can also use vim keys to navigate the scrollback history.
- Its config language is simple enough for the modifications I personally need. I haven't felt that I need to learn the syntax beyond the basics.
- Knowing tmux is also a helpful skill for managing servers, which I do from time to time (my raspberry pi is still running a tmux session from when I last rebooted it).
* 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.
I thought built in theme pickers were the norm…?
Lol, mb, but I don't believe that's the case for Alacritty. As for the Apple Terminal, it is not great
Apple Terminal is a lot like Internet Explorer in the 00s: for power users it’s only purpose is an interface to install something else which doesn’t suck.
As a decrepit old {COMMO} power user, anything that doesn’t give me fully integrated scripting with expect/switch/dialog and a popup script editor, honestly hasn’t been worth investing in further. So I’ve been on Linux console, Putty, and macOS Terminal ever since.
My terminal.app color scheme uses P3 colors on 7% gray rather than the usual sRGB colors so that I can use an OKLCH equidistant palette, and I make extensive use of shift-cmd-up to select and copy “the previous command’s output”. I considered switching for 24-bit color but ultimately I prefer not having to learn a new “rudimentary” app that’s deficient versus my nostalgia just like all the others, and it drastically reduces my stress level when working on other people’s devices that I am proficient in working with an OEM environment.
I occasionally use tabs but for the most part I prefer windows, so that I can drag them around and over/underlapped with other work I’m doing in my GUI. Not a big fan of screen and tmux except as their limited value to me in mitigating ssh disconnects when that’s a concern.
Perhaps your definition of power user is limited to uses aligned with your own?
Oh wow, I haven't thought of COMMO in decades.
I think of it every time I see 'ansible' come up, because the ability to create and run what everyone calls 'playbooks' now should have beeen integrated into the terminal like it was back in the 80s over dialup. I'm all for being able to git commit the resulting script (they’re just text files!) but being able to launch a playbook and halt it and repair it and resume was, like.
Sigh.
I used IE back in the 00s (up until Chrome came out), and I certainly was a power user. I liked it just fine. I think that it's a matter of personal preference rather than something sucking (or not).
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
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?
vscode terminal came in at number 32.
https://ucs-detect.readthedocs.io/sw_results/vscodeterminal....
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.
Ghostty uses GTK + GPU rendering while Foot uses Wayland primitives and CPU rendering.
I've seen zero performance issues with foot.
Foot is the best. Love ctrl-shift-o to open up links
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?
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 :)
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.
I absolutely love it, it's my personal favorite. Using ghostty on MacOS instead.
But I'm no power user.
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.
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.)
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
strangely enough Windows Terminal supports DECDHL but barely any on Linux do!
The table seems wrong. Xterm supports sixels.
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").
You can fix that with a pull request to ucs-detect; for example: https://news.ycombinator.com/item?id=45801452
Only if run with `-ti 340` argument. So in general, it's not there.
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?
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.
They accept PRs on the ucs-detect project for updated test results.
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).
The terminal that comes with macOS version ends on the 29th place in the results.
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.
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.
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.
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.
In 10.10 they added scroll emulation and inline find.
and terminal that comes with Windows is on the 4th place.
the ranking weighed fluffy things i do not want indeed
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.
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".
> 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.
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
Definitely. I use KittyTerminalImages.jl often, and also the image.nvim plugin for embedding images into a Markdown or other buffer in Neovim: https://github.com/3rd/image.nvim
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.
That alternate timeline started in 1982 with the Blit terminal. [0] It was a GUI made of overlapping terminals that had a serial graphics protocol.
[0] https://www.osnews.com/story/26315/blit-a-multitasking-windo...
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.
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.
I didn't know, but I'm happy to hear we seemingly are aligned regardless :) Thanks for the additional context!
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.
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.
I can confirm that I just do it over ssh fine all the time -- gnuplot, img2sixel as an "image-cat", etc. (`st` with patches to add sixel support as discussed in various places in these comments.)
I’ve found it useful, when paired with a terminal file manager, to preview graphics in the terminal.
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.
It would be nice if matplotlib or Octave could display pretty plots and figures on a remote server, in the terminal.
Images in a terminal emulator is neat for stuff like `ranger`
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
FWIW The definitive thread on "images in terminals" is probably found in these threads:
https://gitlab.freedesktop.org/terminal-wg/specifications/-/...
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
I think it's because Kitty and Ghostty are the newest terminals, so they came up with new modern options and solutions.
mitchellh says no plan to support Sixel:
https://xcancel.com/mitchellh/status/1985432954089455856#m
Curious, what do you do with this?
to be fair, pretty much anything would be better than sixels
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.
> 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.
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.
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.
Check x2go.
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.
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 enough to be worth the bother, then we'd all have been using them all along and there wouldn't be posts like this.
It's not a case of there's this awesome idea that just for some reason no one knows about. No, it's just not that awesome of an idea. It's not harmful so it doesn't bother me that most xterms support tektronix graphics, it's just a gimmick of no real value. It's a solution to no problem.
Don't believe me? When was the last time you used passthrough printing? Or saw it being used even in some place where they do actually need to print? The terminals all still support it. It's just a thing that you don't need to do in-band in a tty, and today there is no reason to bother doing it that way even though you could. It's not better and does not solve a problem.
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.
With sshfs and 'rclone mount' you forget the shell and everything it's a filesystem.
What you are looking for is forwarding an X session via SSH, and that has been supported since the dawn of time.
Is there a wayland equivalent?
Yes, waypipe
Closest is wprs
https://github.com/wayland-transpositor/wprs
I have yet to use it though because Wayland still doesn't work properly for me (it doesn't restore the desktop properly after sleep) so I'm still on X11... without compositing... because KWin's compositor causes random freezes.
Yeay, Linux on the Desktop.
> Probably too many GUI naysayers and "What's wrong with remote X?" for this to ever happen though.
drawterm under Unix clients and 9front cpu connections; but that's Unix Philosphy 2.0.
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.
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
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.
Literally none of those is a situation I've ever encountered. I don't think it's as hard to avoid as you think.
> 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.
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.
IMO emojis have no business in any form of text. It just doesn't belong.
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.)
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.
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.
`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
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.
There isn't a single mention of vttest results.
What features tested by vttest, that aren’t measured by ucs-detect, would you want to see added to ucs-detect?
I would use neovide over anything else if they supported macos tabs. It’s the termianl with the best font readability for me.
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.
no xterm.js? it's a very good cross-platform terminal emulator
That seems fixable with a pull request to ucs-detect, if one hasn’t already been made.
good call, you're right
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.
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.
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.
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.
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.
There is an in-terminal wayland compositor (or two?) out there, fwiw.
Edit- one example https://github.com/mmulet/term.everything
well iTerm2 now has a #&*%( web browser built in...
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.
By "browser" here, you mean lynx or links or w3m etc, right?
Assuming so, what would be the benefit of rendering within neomutt instead of lynx?
Does "calling a system provided-component" (WKWebView) count as "built-in"?
Clicking a link to launch an external web browser: no
Viewing a webview inside the app itself: yes
Nothing even mentioned on WezTerm really?
It's in the results, even if not mentioned in the blogpost: https://ucs-detect.readthedocs.io/results.html#general-tabul...
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.
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.
I had some issues with Wezterm fonts - I was able to configure it away: https://github.com/bbkane/dotfiles/tree/master/wezterm#fixed...
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.
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?
> 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.
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).