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.
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.
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.
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.
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.
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)
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.
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.
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?
> 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]
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.
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.
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'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
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?
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.
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?
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.
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.
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
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?
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.
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 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.)
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 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?
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.
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.
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!).
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.
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.
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.
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).
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.
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 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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
Maybe it's hard to find these days. However it had the best VT220 emulation I have seen running on X Window System.
I will note that I have not seen a terminal emulator that supports the "double wide" and "double high, double wide" character modes of the VT100. Those giant letters were kinda fun. (<esc>#3, <esc>#4, and <esc>#6 if my memory serves me right.)
I 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.
> 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.
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.
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.
`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.
> 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.
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).
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.
Agreed, as long as it has a low input latency and allows me to do some basic key re-mapping, I don't really care. Used iterm for a long time as well, but have not touched 95% of the features and it was just a distraction.
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?
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?
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.
6 replies →
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.
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.
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.
5 replies →
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:>
Oh wow, I'm already using ghostty and didn't know about this. It works great, thanks!
3 replies →
Hope Kovid Goyal gets inspired by this
2 replies →
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.
Yeah shift-ins really is the way
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.
3 replies →
Isn't this an X11-ism? I dont believe this is Wayland-specific
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.
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.
How do you paste the selected text if you want to replace a text selection in the other window?
>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.
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?
> 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
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.
1 reply →
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.
> 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.
I have that turned on in Windows Terminal but still use ctrl+c because it's how all other software works
> immediately puts it into the tmux buffer
Can you paste in a non-terminal app though (like a web browser) ?
1 reply →
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'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
It is default in w11 25h2
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?
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.
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?
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.
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.
Yori is also a very capable replacement.
> 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?
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.
1 reply →
So now we are moving away from Keyboard only Vim/Terminal thing to mouse for pasting?
3 replies →
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.
They do emulate a terminal, not just the kind of emulation you have in mind. "Wine is not an emulator" again.
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).
I checked and it was actually the vt240. That one works.
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
2 replies →
I've started working on a VT420 emulator which is about 70% complete: https://github.com/mmastrac/blaze
This also looks closer to the original with some shaders to add pincushion distortion and Gaussian scanlines.
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?
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.
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.
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)
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>.
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.
9 replies →
Relevant GitHub issue: https://github.com/ghostty-org/ghostty/issues/189
2 replies →
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?)
6 replies →
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
11 replies →
The theme picker in Ghostty is above and beyond anything I’ve ever seen in a terminal.
2 replies →
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....
I missed that one!
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.
1 reply →
The terminal emulator knows what font is being used so it should be possible to predict it.
1 reply →
It does it fine with GNU Unifont and raw XTerm and others. I just had issues with RXVT and clones.
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.
Foot is excellent. Wayland only, but it is very fast to launch, and uses few resources. I love it.
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.
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!).
1 reply →
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.
1 reply →
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.
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.
1 reply →
[dead]
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.
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).
They accept PRs on the ucs-detect project for updated test results.
I'd find it very useful to be able to query a terminal to see if it has font support for a given list of characters.
This would allow TUIs to use recent unicode characters which may not be supported (e.g. Symbols for Legacy Computing), or private use characters (e.g. powerline symbols & font-awesome icons), while falling back to a more universally supported character in terminals that do not support them.
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
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.
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.
1 reply →
Accented letters are easy under GNU/Linux or OBSD under X. Just launch:
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.
Literally none of those is a situation I've ever encountered. I don't think it's as hard to avoid as you think.
1 reply →
> 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.
4 replies →
I'd like to see the key-to-pixel latency speed championship.
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
1 reply →
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.
1 reply →
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.
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.
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.
1 reply →
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.
1 reply →
I’ve found it useful, when paired with a terminal file manager, to preview graphics in the terminal.
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`
I think it's because Kitty and Ghostty are the newest terminals, so they came up with new modern options and solutions.
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
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.
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.
1 reply →
> 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.
1 reply →
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.
9 replies →
drawterm under Unix clients and 9front cpu connections; but that's Unix Philosphy 2.0.
>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.
Curious, what do you do with this?
mitchellh says no plan to support Sixel:
https://xcancel.com/mitchellh/status/1985432954089455856#m
to be fair, pretty much anything would be better than sixels
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...
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.
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!
While there's vscode console, I think that bare Xterm.js would be a nice addition to the list.
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.
it is also a lot easier on the battery than iterm2
> 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.
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.
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.
1 reply →
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.
1 reply →
Does "calling a system provided-component" (WKWebView) count as "built-in"?
1 reply →
`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.
> 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.
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).
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?
a look at terminal emulators
https://lwn.net/Articles/749992/
https://lwn.net/Articles/751763/
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.
Why are we still emulating dumb terminals in 2025?
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
[dead]
[dead]
Agreed, as long as it has a low input latency and allows me to do some basic key re-mapping, I don't really care. Used iterm for a long time as well, but have not touched 95% of the features and it was just a distraction.
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?
[flagged]
Are you implying that the article is bunk? What do you see as a better compendium than this?
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.
1 reply →
> 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 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.
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).
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?
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.