11 ms·

State of Terminal Emulators in 2025: The Errant Champions

267 points by SG- 11mo ago

audidude 11mo ago
So the state of 2025 then tests a VTE that is from 2023? 4 major releases behind? And through a GTK 3 app, not even a GTK 4 one which will use the GPU?
- embedding-shape 11mo ago
  Which one is that about specifically? Maybe the author could fix it. Compared the results (https://ucs-detect.readthedocs.io/results.html#general-tabulated-summary https://ucs-detect.readthedocs.io/results.html#general-tabul...) with what I use day-to-day (Alacritty) and seems the results were created with the same version I have locally installed, from Arch/CachyOS repos, namely 0.16.1 (42f49eeb).
- milliams 11mo ago
  Likewise I noticed that Konsole was version 23.08. I've just submitted a PR (https://github.com/jquast/ucs-detect/pull/14 https://github.com/jquast/ucs-detect/pull/14) to update it to 25.08.
- aidenn0 11mo ago
  They accept PRs on the ucs-detect project for updated test results.
scuderiaseb 11mo ago
Nothing even mentioned on WezTerm really?
- embedding-shape 11mo ago
  It's in the results, even if not mentioned in the blogpost: https://ucs-detect.readthedocs.io/results.html#general-tabulated-summary https://ucs-detect.readthedocs.io/results.html#general-tabul...
- greggh 11mo ago
  People still use WezTerm when we have Kitty and Ghostty? Can you explain why? I'm actually interested to know what would make someone make that choice.
  - alwillis 11mo ago
    > People still use WezTerm when we have Kitty and Ghostty? Very customizable and extensible using Lua. Extensive documentation, native ssh support and built-in multiplexing.
  - pneumic 11mo ago
    Wezterm is actually programmable. I am looking to drop Kitty as it intentionally offers minimal tmux support and the text rendering options that made it superior for me are being deprecated. Until Ghostty offers the scriptability found in wezterm and kitty (e.g., hit a keybind, spawn a new terminal and execute a font picker script), I am trying out wezterm, which is pretty great, but renders fonts too thin by default. I stare at this thing eight hours a day so text rendering is super important.
    - bbkane 11mo ago
      I had some issues with Wezterm fonts - I was able to configure it away: https://github.com/bbkane/dotfiles/tree/master/wezterm#fixed---font-rendering https://github.com/bbkane/dotfiles/tree/master/wezterm#fixed...
  - sigmonsays 11mo ago
    I prefer WezTerm over ghosttty and kitty. I prefer it's UI and level of customization. Ghostty animations run like crap for me on linux (not sure why).
  - bbkane 11mo ago
    Folks have responded about WezTerm's programmability being the reason they like it, but if you don't mind I'd like to flip the question around: why do you prefer Kitty or Ghostty to WezTerm?
  - 11mo ago
- rashil2000 11mo ago
  I love WezTerm! Recently switched from iTerm2 and programmed the hell out of it: https://rashil2000.me/blogs/tune-wezterm https://rashil2000.me/blogs/tune-wezterm. It has a very extensive Lua API.
skerit 11mo ago
I see Ghostty does not support (and does not plan on adding support for) Sixels, instead preferring the Kitty image protocol. Now if the Kitty image protocol is so great and the Sixel stuff is so bad, ~~why is it only used in Kitty and Ghostty?~~ *Edit: it's also supported in Konsole, WezTerm, ... but still I'm interested in why we have 2 competing protocols right now.
- didibus 11mo ago
  I think it's because Kitty and Ghostty are the newest terminals, so they came up with new modern options and solutions.
- embedding-shape 11mo ago
  > Now if the Kitty image protocol is so great and the Sixel stuff is so bad, why is it only used in Kitty and Ghostty? Images as in "pictures" or is that something else? I'm using Alacritty, and I don't think I've once thought "I need to see this image inside the terminal" and I do deal with images and frames from videos a lot. Probably if I saw it being added to Alacritty I'd think it was adding unnecessary bloat, so I wouldn't be surprised not every terminal is rushing to implement it. Or I completely misunderstand what you're talking about.
  - porridgeraisin 11mo ago
    Yes, pictures. It's quite useful. Opening images on remotes for one. Viewing plots arbitrary python scripts create for another. Off the top of my head.
  - alwillis 11mo ago
    I’ve found it useful, when paired with a terminal file manager, to preview graphics in the terminal.
  - the_gipsy 11mo ago
    The alacritty maintainers reject any image protocols as unnecessary. I am fond of images in terminals, but I gotta say that I respect their decision, very good call. Not every terminal emulator should do the same.
bartvk 11mo ago
The terminal that comes with macOS version ends on the 29th place in the results.
- sccxy 11mo ago
  and terminal that comes with Windows is on the 4th place.
- alwillis 11mo ago
  Yeah… Apple hasn't done much with Terminal.app since they inherited it from NeXT back in the late '90s. FWIW, it did get Powerline support and 24-bit color in macOS 26.
  - krackers 11mo ago
    In 10.10 they added scroll emulation and inline find.
- sitzkrieg 11mo ago
  the ranking weighed fluffy things i do not want indeed
- doug_durham 11mo ago
  Yeah, I don't understand. I spend my day in the macOS terminal app and the thought "Hey I'd like a better terminal" has never occurred to me.
  - toast0 11mo ago
    Maybe it's better now, but when I started my time on OSX, the built in terminal defaulted to "unlimited" scrollback, so if you were used to tailing giant log files, it would beachball pretty quick. I spent the rest of my time using iterm2 instead; it defaulted to a sensible scrollback length; and at some point it added a progress bar when you made a giant paste.
  - cosmic_cheese 11mo ago
    Perhaps my needs are too pedestrian, but I don't believe I've ever needed anything more than what the macOS Terminal app is capable of. I've tried the vaunted iTerm2 and Ghostty among others but they never stuck.
Asooka 11mo ago
I wonder how long until terminals support half of the XWindows protocol (as some weird combination of Markdown, HTML and escape codes, most probably). This is not a diss, I would actually be pretty happy with a pared-down GUI protocol in the terminal with extensive Unicode support.
- sph 11mo ago
  2052: the whole of computing is VT100-compatible Javascript CLI applications running on a Javascript port of the Linux kernel, within a tab of Chromium. This is the actual end game of the worse is better philosophy.
  - anthk 11mo ago
    It's 9front actually. VT100 it's killed except for legacy plaforms, it's seen like CP/M and Altair emulators where looked upon 1995-2000. 9front's libc with a minimal desktop based on a tweaked rio(1) and a taskbar plus a really simple file manager won. People god fed up of FX' and bells and whistles everywhere. A minimal RTF editor with simple options plus a simple spreadsheet with rc/awk support does things much faster. Oh, and, of course, you can damn bind/import devices (video cards, network cards, whole networks) from anywhere to anywhere with IPV6 and quantum networks. Old GNU/Linuxen, OpenBSD et all are just virtualized at crazy speeds under photonic CPU's. There's no SSH, just rcpu and quantum-secured factotum(1). Photonic GPU's and neural network devices just boot 9front themselves too, with zero delay. Forget VPN's, too. These are obsolete too.
    - sph 11mo ago
      Ha! Your vision is positive, and idealistic. (Plan 9 is never make a come back, sorry to say) My comment was sarcastic, and wishing that we at least tried to move away from UNIX, VT100 and mainframe-style computing; trying something new instead of continuously retreading old ground. Gary Bernhardt said it best: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- temp0826 11mo ago
sxndmxn 11mo ago
[flagged]
- lolptdr 11mo ago
  Are you implying that the article is bunk? What do you see as a better compendium than this?
mfld 11mo ago
While there's vscode console, I think that bare Xterm.js would be a nice addition to the list.
iammrpayments 11mo ago
I would use neovide over anything else if they supported macos tabs. It’s the termianl with the best font readability for me.
- duskwuff 11mo ago
  Disappointingly, the native UI for tabbed windows on macOS changed drastically in Tahoe (26.0). I really dislike the new tabs - they're significantly larger, and much harder to integrate into a small window like a terminal.
acuozzo 11mo ago
There isn't a single mention of vttest results.
- altairprime 11mo ago
  What features tested by vttest, that aren’t measured by ucs-detect, would you want to see added to ucs-detect?
alkh 11mo ago
I have been pretty happy with Alacritty for a while but just tried Ghostty and am a little bit mind-blown. The fact that it has a built-in theme picker is insanely convenient for people working on multiple computers at the same time(so the same theme might not work everywhere). Overall, it literally looks like a better Alacritty alternative. The creator(s) did a great job!
- hnlmorg 11mo ago
  I thought built in theme pickers were the norm…?
  - alkh 11mo ago
    Lol, mb, but I don't believe that's the case for Alacritty. As for the Apple Terminal, it is not great
    - hnlmorg 11mo ago
      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.
      - altairprime 11mo ago
        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?
bsimpson 11mo ago
The same part of me that is shy to install Chrome extensions is shy to try non-standard terminals. I'd like the thing I type my passwords into to be as trusted as possible. SteamOS comes with Konsole, so that's what I've got installed in Linux. What am I missing out on by not using e.g. Ghostty? (I know this article is about Unicode support, but I don't think I've ever had a hard time using a terminal because of its level of Unicode support.)
- jeffbee 11mo ago
  So, don't type your password into your terminal emulator? In many situations (ssh and suchlike) you can use another means of unlocking your credentials.
- tristan957 11mo ago
  If Konsole suits your needs, there is no reason to move to Ghostty. You may find better performance or access to more terminal features, but if those don't move the needle for you, then it doesn't matter. Konsole is well integrated in to KDE.
zadjii 11mo ago
No love for Windows Terminal? I know that linux has a much richer terminal ecosystem, but WT ranks a lot higher than a wide breadth of terminal emulators on linux now. Could anyone have imagined that 10 years ago?
- gschizas 11mo 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 https://www.youtube.com/watch?v=8gw0rXPMMPE :) EDIT: I love the easter egg with the names of the developers across the Windows timeline :)
- TacticalCoder 11mo ago
  [dead]
- epolanski 11mo ago
  I absolutely love it, it's my personal favorite. Using ghostty on MacOS instead. But I'm no power user.
  - bigstrat2003 11mo ago
    I would argue that anyone who uses the terminal enough to have opinions on which one they like best is very much a power user.
    - epolanski 11mo ago
      I don't know, reading around feels like power users are mostly defined but the tons of features they use and miss when switching emulators.
- jscyc 11mo 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.
jeffbee 11mo ago
It's interesting that these are rankings, but in some cases the individual points are make or break for a given use case. For example, none of the emulators ranked higher than iTerm2 support Tek 4010 mode, which iTerm2 does support. So that's the one I keep using.
- alwillis 11mo ago
  It would amazing if iTerm used the Ghostty library (libghostty) for the core terminal functionality; then the developer could focus on UI/UX. iTerm has tons of useful features, but a lot of them are buried in the UI.
electroglyph 11mo ago
no xterm.js? it's a very good cross-platform terminal emulator
- altairprime 11mo ago
  That seems fixable with a pull request to ucs-detect, if one hasn’t already been made.
  - electroglyph 11mo ago
    good call, you're right
christophilus 11mo ago
Foot is excellent. Wayland only, but it is very fast to launch, and uses few resources. I love it.
- ac29 11mo ago
  Yep this is my current favorite too. I liked ghostty when I evaluated it, but for some reason it uses an order of magnitude more memory than foot to display a single, empty terminal.
  - tristan957 11mo ago
    Ghostty uses GTK + GPU rendering while Foot uses Wayland primitives and CPU rendering.
    - colordrops 11mo ago
      I've seen zero performance issues with foot.
      - tristan957 11mo ago
        My comment was not to imply that Ghostty performed better than Foot. Foot is a great terminal.
- colordrops 11mo ago
  Foot is the best. Love ctrl-shift-o to open up links
- RVuRnvbM2e 11mo ago
  I'm quite confused why this article tests foot v1.16.2, which is two years old at this point. The latest version is 1.25.0. By contrast, the tested version of ghostty v1.2.3 is two weeks old.
  - aorth 11mo ago
enriquto 11mo ago
The table seems wrong. Xterm supports sixels.
- altairprime 11mo ago
  You can fix that with a pull request to ucs-detect; for example: https://news.ycombinator.com/item?id=45801452 https://news.ycombinator.com/item?id=45801452
- the_gipsy 11mo ago
  Only if run with `-ti 340` argument. So in general, it's not there.
- omoikane 11mo ago
  Same for mintty. I tried `echo "\e[c"` (send device attributes) on mintty 2.8.1 just now and got "4" back ("VT132 with Advanced Video and Graphics").
cb321 11mo ago
`st` used to have a patch set for sixel graphics on its web site. I use an old version all the time to do gnuplots in terminals with nice scrollback. It seems to have been retired in favor of the kitty graphics protocol.
- imiric 11mo ago
  This[1] is an up-to-date fork with sixel support, and a few other patches. IMO it's unfair to compare barebones `st` with fully-featured terminals. The entire point of `st` is for users to apply their own patches to it, which does make it difficult to compare, since there's no standard version of it. `st` is a pretty great terminal. I switched to `foot` when I migrated to Wayland a few months ago, but not for any practical reasons other than wanting to rely less on Xwayland. [1]: https://github.com/veltza/st-sx https://github.com/veltza/st-sx
  - cb321 11mo ago
    I 100% agree `st` is pretty great and comparing bare bones is unfair. Thanks for that link! I suppose I should have provided a link to the variant I use which is https://github.com/bakkeby/st-flexipatch 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.
topaz0 11mo ago
I can't remember the last time I used a non-ascii character in the terminal. I know that's not the case for everyone, and they deserve good terminals too, but it does mean that the criteria measured here have no relevance to my choice of a good terminal for me.
- ubercow13 11mo ago
  Seems quite hard to avoid - file management such as running "ls" where any filename has any non-ascii character such as a CJK or accented letter - editing any text file in a terminal editor that isn't 100% ascii - viewing/printing any data from any source, such as a log file/the web/'curl'ing something, where any language other than English or non-ascii character is used - using various modern command line tools that insist on printing emojis in their output
  - hnlmorg 11mo ago
    > using various modern command line tools that insist on printing emojis in their output Ugh. Unpopular opinion this but I personally find this practice repugnant. Same for when used in git commit messages, CI/CD task names and other such places. It just cheapens the quality of the product in my opinion Graphical characters and symbols like ticks I’m fine with. I have no objection to people wanting to make the terminal pretty. But emojis in software feels like juvenile - like signing a formal letter with your gaming handle.
    - epolanski 11mo ago
      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.
      - pseudalopex 11mo ago
        I want country codes not flags. And check marks do not require emoji. Every emoji I saw in a terminal or Git commit message was worse than alternatives. This included emoji intended for information not fun. Color made them distracting when the wanted information was anything else. A monochrome font could not solve this because most emoji are too complex to display clearly at normal text sizes without color. They were cumbersome to grep. (Uncommon Unicode characters would have this problem also.) Many had unclear meanings. Use emoji in your CLIs if you desire. But make them optional. Opt in ideally.
imiric 11mo ago
> And then my next windmill that I'm looking at is variable-sized text in the terminal. So when I'm catting a markdown file, I want to see the headings big. Is this something people actually want? One of the reasons I enjoy using the terminal is because the text is of a fixed size and monospaced. Even colors and bold text can be distracting at times. I certainly don't want my terminal to render Markdown... I imagine the feature could be disabled, but still. I'm all for improving terminal UIs, but let's not turn them into a web browser.
joouha 11mo ago
I'd find it very useful to be able to query a terminal to see if it has font support for a given list of characters. This would allow TUIs to use recent unicode characters which may not be supported (e.g. Symbols for Legacy Computing), or private use characters (e.g. powerline symbols & font-awesome icons), while falling back to a more universally supported character in terminals that do not support them.
loph 11mo ago
The list does not include DECterm. https://stuff.mit.edu/afs/net/dev/system/pmax_ul3/srvd.74/usr/lib/X11/help/dxterm/Overview 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.)
- dgl 11mo ago
  xterm does and some others, I posted about this and emojis a while ago: https://dgl.cx/2025/06/can-your-terminal-do-emojis https://dgl.cx/2025/06/can-your-terminal-do-emojis
  - altairprime 11mo ago
    (161 comments) https://news.ycombinator.com/item?id=44362272 https://news.ycombinator.com/item?id=44362272
- unleaded 11mo ago
  strangely enough Windows Terminal supports DECDHL but barely any on Linux do!
tmtvl 11mo ago
Some vaguely related things: - VTTEST <https://invisible-island.net/vttest/vttest.html 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 https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt>.
unleaded 11mo ago
It's interesting that none of the programs commonly known as "terminal emulators" actually emulate a terminal.. we can do that now though. https://zork.net/~st/jottings/Real-VT102-emulation-with-MAME.html https://zork.net/~st/jottings/Real-VT102-emulation-with-MAME... I would avoid doing the PTY thing and instead do this (works on WSL if MAME is the windows version): $ sudo socat TCP-LISTEN:1234,reuseaddr,fork EXEC:"/sbin/agetty -L - 9600 vt102",pty,setsid,ctty,stderr $ mame -nomouse vt102 -rs232 null_modem -bitb socket.localhost:1234 You can do the same thing with a vt220. I've had an idea to try to write a sort of high-level-ish VT220 emulator that pokes and patches the ROMs and the system to let you control it with the mouse, paste and stuff, lets you just doubleclick it to get a terminal, etc... I forgot about that until seeing this. Nobody would use it for more than 5 minutes but it would be funny.
- dgl 11mo ago
  If MAME could support the VT525 (nearly the last terminal DEC made and unlike the previous DEC models it supports ANSI color) people might use it a bit more. It would be very useful for compatibility testing as there aren't many people with a real VT525! Last I looked someone had dumped the ROMs but there wasn't any support code.
  - p_l 11mo ago
    VT5xx was the budget line with limited functionality, that's why only 525 among them supports ANSI color. The only fancy stuff was multisession (TD/SMP if you have all bits to support it) and "desktop accessories" like clock and calculator. The really interesting ones are VT340 variants with ReGIS and full SIXEL graphics
    - dgl 11mo ago
      The VT3xx ones that were color did not support ANSI SGR to set them. I don't think VT5xx was a budget line, it has more escape sequences than the previous ones (including interesting ones like changing cursor shape, which modern terminals implement too). It's more that they never made a graphical version of the VT5xx (this was the early 90s, whether physical VTs made sense anymore is debatable, but terminal graphics likely didn't). VT340 is definitely interesting and if someone were to emulate one that would also be great! (there's been some good research, e.g.: https://github.com/hackerb9/vt340test https://github.com/hackerb9/vt340test, which you might be surprised to learn has been used to make Windows Terminal one of the more conformant terminals...)
sho_hn 11mo ago
Pretty nice to see KDE's Konsole rank really high, especially if you take performance/test elapsed time into account. Considering it's a decades-older workhorse compared to the new star ghostty, not too shabby that it's kept up.
- yokljo 11mo ago
  Agreed. It's nice to be able to just use the provided terminal when running KDE. It's very customisable and runs plenty fast. I also love being able to right click on Dolphin and tell it to open Konsole in the current folder. Also, I leave infinite scroll back turned on in Konsole and it works really well, swapping out to a file as it gets too much scroll back. Nothing worse than getting errors that I can't read because the terminal discarded them. I have Ctrl+Shift+X bound to clear everything, which I use before running just about any operation.
  - jcgl 11mo ago
    > I also love being able to right click on Dolphin and tell it to open Konsole in the current folder. This is a KDE thing; it'll open in whatever terminal you've got configured in Default Applications.
- whateveracct 11mo ago
  Konsole Just Works
- TiredOfLife 11mo ago
  Unfortunately Konsole has this feature that each time you switch tabs the maximized window shrinks by a couple of pixels (at least on Steam Deck)
j1elo 11mo ago
Work had me using the Windows Terminal for the first time ever after a life of developing on Linux. I got immediately hooked on the smart Ctrl+C and Ctrl+V (without needing to use Shift like on Linux!) For those not knowing, Windows Terminal uses Ctrl+C to abort the current process (as we'd expect) when nothing is selected, but copies when there is a selection. Similarly, Ctrl+V just pastes. So convenient!
- stefanha 11mo ago
  In Linux (Wayland) you can copy text from the terminal without pressing Ctrl+C at all. Just select the text. To paste it in another Window, press the middle mouse button. This is called the Primary Selection and is separate from the Clipboard (Ctrl+C/Ctrl+V). IMO the Primary Selection is more convenient than the Clipboard.
  - j1elo 11mo ago
    Yeah I know. I missed this for the first couple days, but didn't take much before forgetting it after the change to Windows. (anyway I keep using Linux at home)
  - DaSHacka 11mo ago
    Isn't this an X11-ism? I dont believe this is Wayland-specific
  - lelandbatey 11mo ago
    This is also a thing in X, not only Wayland.
  - pmontra 11mo ago
    That's an X11 thing that Wayland had to reimplement because it's so convenient. The problem is when pasting into the terminal something that another program copied into the clipboard. That's ctrl-shift-c. I thought about remapping copy and paste to their own keys, possibly a single one. Maybe on the number pad, which I never use. Or remapping ctrl-c.
ctippett 11mo ago
I appreciate this analysis is on the state of terminal emulators, but I'm curious how well the integrated terminals that come bundled in code editors/IDEs also perform. For example, where does Zed's integrated terminal fit in the rankings? VS Code (and its derivatives)? JetBrains, Sublime Text?
- kartoffelmos 11mo ago
  vscode terminal came in at number 32. https://ucs-detect.readthedocs.io/sw_results/vscodeterminal.html#vscodeterminal https://ucs-detect.readthedocs.io/sw_results/vscodeterminal....
  - ctippett 11mo ago
    I missed that one!
uvaursi 11mo ago
I still use PuTTY and a MAX232EACwhateverthefuck chip for embedded hardware stuff with a DB9 cable thats been plugged in and out more times than your mom on prom night. Should I switch to something else or just keep on truckin?
shirro 11mo ago
Terminal emulators are caught between emulating terminals and teletypes of the past and implementing new features and unicode is one of the struggles. The way most terminals and wcwidth handle the width of characters sometimes is not correct but preserving behavior is important for compatibility. It is possible that its just not worth trying to handle all unicode perfectly in a terminal. Its pretty good for legacy stuff and sysadmin. We have other ways of doing things remotely like html that might be more appropriate for ZWJ emoji and languages with complicated text shaping/rendering.
- kevin_thibedeau 11mo ago
  For glyph width, there are codepoints classified as ambiguous width. These are mostly narrow pre-emoji symbols that have been extended with an alternate emoji representation. There's no way to predict what their width will be, even with explicit variation selectors which might just be ignored.
  - charcircuit 11mo ago
    The terminal emulator knows what font is being used so it should be possible to predict it.
    - kevin_thibedeau 11mo ago
      The terminal application doesn't know the font. The best you can do is discover ambiguous widths by printing codepoints and checking the change in cursor position. That's a suboptimal experience.
  - lifthrasiir 11mo ago
    > These are mostly narrow pre-emoji symbols that have been extended with an alternate emoji representation. Nitpick: this is incorrect. Easy counter-examples would be arrow symbols like →. UAX #11 helpfully explains what is "ambiguous" about those characters: Ambiguous characters occur in East Asian legacy character sets as wide characters, but as narrow (i.e., normal-width) characters in non–East Asian usage. (Examples are the basic Greek and Cyrillic alphabet found in East Asian character sets, but also some of the mathematical symbols.) Private-use characters are considered ambiguous by default, because additional information is required to know whether they should be treated as wide or narrow. In the other words, these characters have been commonly available in both Asian and non-Asian character sets and assigned different widths by them.
deleted 11mo ago
[deleted]
musicale 11mo ago
I'd like to see the key-to-pixel latency speed championship.
eschatology 11mo ago
While the article title is true (errant is a very specific and concise word), to me it did not convey clear enough that this is just ucs-detect / unicode support (compliance?) ranking. The article title "State of Terminal Emulators in 2025" implied a larger comparison of terminal emulators than just ucs-detect. Personally I also question the practicality or usefulness of this table because why should I care about having "the best unicode support"? Curious, I briefly compared top ranked emulator (ghostty) on how fast it can print 10000 lines and it took 432ms compared to alacritty, ranked 18 (50ms), and Terminal.app, ranked 29 (50ms). If this is the trade-off to have the best unicode support, why should I want it? Why does it matter?
- bardsore 11mo ago
  How fast my terminal can print 10000 lines is pretty far down the list of requirements I have, who cares as long as it is fast enough? To me it is as irrelevant as who has the best unicode support.
ivanjermakov 11mo ago
Unicode support in terminals is kind of a mess for TUI software developers. There is no good way to know how many columns a Unicode character will take, because terminals use different grapheme clustering algorithms. For a text editor I'm making I ended up with: > Unicode support is limited to what common modern terminal emulators support. In Hat, "character" is a Unicode codepoint. So no grapheme clustering, no variation selection, no ZWJs, no terminal emulator-specific logic. As long as every buffer byte is displayed and editable, we're ok. https://github.com/ivanjermakov/hat/blob/master/CONTRIBUTING.md 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/00782dbaee1e1a814cea43c4f837aad2ac9a591e/src/unicode.zig#L63 https://github.com/ivanjermakov/hat/blob/00782dbaee1e1a814ce...
Piraty 11mo ago
a look at terminal emulators https://lwn.net/Articles/749992/ https://lwn.net/Articles/749992/ https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/
sanskarix 11mo ago
[dead]
sanskarix 11mo ago
[dead]
- dmaa 11mo ago
  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.
dmaa 11mo ago
I used iterm2 for ages, but then somehow defaulted to terminal.app. It is fast and that is basically all i need from a terminal emulator, everything else is taken care of by tmux.
- krautburglar 11mo ago
  it is also a lot easier on the battery than iterm2
p_l 11mo ago
Interesting that xterm is written off as not supporting sixel, when in actuality it supports both full SIXEL and ReGIS and Tek 4010, with 24bit colour IIRC. It's just not enabled by default.
Joker_vD 11mo ago
> Kitty and Ghostty are the only terminals that correctly support Variation Selector 15, Really? Because IIRC they "support" it by treating the preceding emoji character as being Narrow instead of Wide. This is completely unsupported by anything in the Unicode standards: the codepoint sequences that affect the East Asian Width of their first codepoints are explicitly enumerated, and none of them have emojis and/or VS-15 in it. So no, it's not "correctly" supported. Emojis are Wide (terminal width 2) with or without VS-15/VS-16, and if fonts have textual renditions of them that are only 1 cell wide, well, that's the fonts' problems, just as fonts that have e.g. glyphs for Playing Cards block with visible width of 1.5 (I am looking at you, Google Noto) are wrong too.
- j4_james 11mo ago
  Agreed. The only thing that VS-15 is supposed to do is give the emoji a "text presentation", which the spec suggests as "black & white". And every example they show of a text presentation is exactly the same width as the emoji presentation. Changing a character's width from wide to narrow after it has already been output is fraught with problems for a terminal. Imagine trying to write a "narrow" text presentation emoji in the bottom right corner of the screen. You'd think it should fit, but the emoji is received before the VS-15 selector, and that doesn't fit, so the terminal is forced to wrap the text, triggering a scroll of the entire page. By the time the VS-15 arrives, there's no way to undo all of that. And for another example, try using IRM (insert replace mode) to insert a text presentation emoji in the middle of some existing text. If it was really narrow, you'd expect it to insert enough space for just one character, but it actually inserts two spaces, only occupying one of them, and then leaving an unexpected gap. And the more of these "narrow" characters you insert, the bigger the gap becomes. VS-16 changing a text presentation character from narrow to wide doesn't share these problems. And that behaviour is supported by the spec text, which says that emoji should generally have a square aspect ratio. And at one time the East Asian Width spec specifically mentioned VS-16 making narrow characters wide (but said nothing about VS-15 making wide characters narrow).
UltraSane 11mo ago
Why are we still emulating dumb terminals in 2025?
childintime 11mo ago
These terminals properly handle single + double width fonts. But the same thing could work with single + half width fonts, so i,j,l,:,!,.,' and space would fit in half the width. Does anyone know of such a font? I searched but couldn't find any bi-spaced font with full/half width cells. It would not only fit more text on a line, while (probably) also being nearly as pleasing as a proportional font, but it would also still perfectly align indents. I think it could be a great markdown font.
- akho 11mo ago
  Indents align perfectly in any font. Alignment in columns (like what go fmt likes) is problematic.

267 points by SG- 11mo ago

So the state of 2025 then tests a VTE that is from 2023? 4 major releases behind? And through a GTK 3 app, not even a GTK 4 one which will use the GPU?

embedding-shape 11mo ago
Which one is that about specifically? Maybe the author could fix it. Compared the results (https://ucs-detect.readthedocs.io/results.html#general-tabulated-summary https://ucs-detect.readthedocs.io/results.html#general-tabul...) with what I use day-to-day (Alacritty) and seems the results were created with the same version I have locally installed, from Arch/CachyOS repos, namely 0.16.1 (42f49eeb).
milliams 11mo ago
Likewise I noticed that Konsole was version 23.08. I've just submitted a PR (https://github.com/jquast/ucs-detect/pull/14 https://github.com/jquast/ucs-detect/pull/14) to update it to 25.08.
aidenn0 11mo ago
They accept PRs on the ucs-detect project for updated test results.

scuderiaseb 11mo ago

Nothing even mentioned on WezTerm really?

embedding-shape 11mo ago
It's in the results, even if not mentioned in the blogpost: https://ucs-detect.readthedocs.io/results.html#general-tabulated-summary https://ucs-detect.readthedocs.io/results.html#general-tabul...
greggh 11mo ago
People still use WezTerm when we have Kitty and Ghostty? Can you explain why? I'm actually interested to know what would make someone make that choice.
- alwillis 11mo ago
  > People still use WezTerm when we have Kitty and Ghostty? Very customizable and extensible using Lua. Extensive documentation, native ssh support and built-in multiplexing.
- pneumic 11mo ago
  Wezterm is actually programmable. I am looking to drop Kitty as it intentionally offers minimal tmux support and the text rendering options that made it superior for me are being deprecated. Until Ghostty offers the scriptability found in wezterm and kitty (e.g., hit a keybind, spawn a new terminal and execute a font picker script), I am trying out wezterm, which is pretty great, but renders fonts too thin by default. I stare at this thing eight hours a day so text rendering is super important.
  - bbkane 11mo ago
    I had some issues with Wezterm fonts - I was able to configure it away: https://github.com/bbkane/dotfiles/tree/master/wezterm#fixed---font-rendering https://github.com/bbkane/dotfiles/tree/master/wezterm#fixed...
- sigmonsays 11mo ago
  I prefer WezTerm over ghosttty and kitty. I prefer it's UI and level of customization. Ghostty animations run like crap for me on linux (not sure why).
- bbkane 11mo ago
  Folks have responded about WezTerm's programmability being the reason they like it, but if you don't mind I'd like to flip the question around: why do you prefer Kitty or Ghostty to WezTerm?
- 11mo ago
rashil2000 11mo ago
I love WezTerm! Recently switched from iTerm2 and programmed the hell out of it: https://rashil2000.me/blogs/tune-wezterm https://rashil2000.me/blogs/tune-wezterm. It has a very extensive Lua API.

skerit 11mo ago

I see Ghostty does not support (and does not plan on adding support for) Sixels, instead preferring the Kitty image protocol. Now if the Kitty image protocol is so great and the Sixel stuff is so bad, ~~why is it only used in Kitty and Ghostty?~~ *Edit: it's also supported in Konsole, WezTerm, ... but still I'm interested in why we have 2 competing protocols right now.

didibus 11mo ago
I think it's because Kitty and Ghostty are the newest terminals, so they came up with new modern options and solutions.
embedding-shape 11mo ago
> Now if the Kitty image protocol is so great and the Sixel stuff is so bad, why is it only used in Kitty and Ghostty? Images as in "pictures" or is that something else? I'm using Alacritty, and I don't think I've once thought "I need to see this image inside the terminal" and I do deal with images and frames from videos a lot. Probably if I saw it being added to Alacritty I'd think it was adding unnecessary bloat, so I wouldn't be surprised not every terminal is rushing to implement it. Or I completely misunderstand what you're talking about.
- porridgeraisin 11mo ago
  Yes, pictures. It's quite useful. Opening images on remotes for one. Viewing plots arbitrary python scripts create for another. Off the top of my head.
- alwillis 11mo ago
  I’ve found it useful, when paired with a terminal file manager, to preview graphics in the terminal.
- the_gipsy 11mo ago
  The alacritty maintainers reject any image protocols as unnecessary. I am fond of images in terminals, but I gotta say that I respect their decision, very good call. Not every terminal emulator should do the same.

bartvk 11mo ago

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

sccxy 11mo ago
and terminal that comes with Windows is on the 4th place.
alwillis 11mo ago
Yeah… Apple hasn't done much with Terminal.app since they inherited it from NeXT back in the late '90s. FWIW, it did get Powerline support and 24-bit color in macOS 26.
- krackers 11mo ago
  In 10.10 they added scroll emulation and inline find.
sitzkrieg 11mo ago
the ranking weighed fluffy things i do not want indeed
doug_durham 11mo ago
Yeah, I don't understand. I spend my day in the macOS terminal app and the thought "Hey I'd like a better terminal" has never occurred to me.
- toast0 11mo ago
  Maybe it's better now, but when I started my time on OSX, the built in terminal defaulted to "unlimited" scrollback, so if you were used to tailing giant log files, it would beachball pretty quick. I spent the rest of my time using iterm2 instead; it defaulted to a sensible scrollback length; and at some point it added a progress bar when you made a giant paste.
- cosmic_cheese 11mo ago
  Perhaps my needs are too pedestrian, but I don't believe I've ever needed anything more than what the macOS Terminal app is capable of. I've tried the vaunted iTerm2 and Ghostty among others but they never stuck.

Asooka 11mo ago

I wonder how long until terminals support half of the XWindows protocol (as some weird combination of Markdown, HTML and escape codes, most probably). This is not a diss, I would actually be pretty happy with a pared-down GUI protocol in the terminal with extensive Unicode support.

sph 11mo ago
2052: the whole of computing is VT100-compatible Javascript CLI applications running on a Javascript port of the Linux kernel, within a tab of Chromium. This is the actual end game of the worse is better philosophy.
- anthk 11mo ago
  It's 9front actually. VT100 it's killed except for legacy plaforms, it's seen like CP/M and Altair emulators where looked upon 1995-2000. 9front's libc with a minimal desktop based on a tweaked rio(1) and a taskbar plus a really simple file manager won. People god fed up of FX' and bells and whistles everywhere. A minimal RTF editor with simple options plus a simple spreadsheet with rc/awk support does things much faster. Oh, and, of course, you can damn bind/import devices (video cards, network cards, whole networks) from anywhere to anywhere with IPV6 and quantum networks. Old GNU/Linuxen, OpenBSD et all are just virtualized at crazy speeds under photonic CPU's. There's no SSH, just rcpu and quantum-secured factotum(1). Photonic GPU's and neural network devices just boot 9front themselves too, with zero delay. Forget VPN's, too. These are obsolete too.
  - sph 11mo ago
    Ha! Your vision is positive, and idealistic. (Plan 9 is never make a come back, sorry to say) My comment was sarcastic, and wishing that we at least tried to move away from UNIX, VT100 and mainframe-style computing; trying something new instead of continuously retreading old ground. Gary Bernhardt said it best: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
temp0826 11mo ago

sxndmxn 11mo ago

[flagged]

lolptdr 11mo ago
Are you implying that the article is bunk? What do you see as a better compendium than this?

mfld 11mo ago

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

iammrpayments 11mo ago

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

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

acuozzo 11mo ago

There isn't a single mention of vttest results.

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

alkh 11mo ago

I have been pretty happy with Alacritty for a while but just tried Ghostty and am a little bit mind-blown. The fact that it has a built-in theme picker is insanely convenient for people working on multiple computers at the same time(so the same theme might not work everywhere). Overall, it literally looks like a better Alacritty alternative. The creator(s) did a great job!

hnlmorg 11mo ago
I thought built in theme pickers were the norm…?
- alkh 11mo ago
  Lol, mb, but I don't believe that's the case for Alacritty. As for the Apple Terminal, it is not great
  - hnlmorg 11mo ago
    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.
    - altairprime 11mo ago
      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?

bsimpson 11mo ago

The same part of me that is shy to install Chrome extensions is shy to try non-standard terminals. I'd like the thing I type my passwords into to be as trusted as possible. SteamOS comes with Konsole, so that's what I've got installed in Linux. What am I missing out on by not using e.g. Ghostty? (I know this article is about Unicode support, but I don't think I've ever had a hard time using a terminal because of its level of Unicode support.)

jeffbee 11mo ago
So, don't type your password into your terminal emulator? In many situations (ssh and suchlike) you can use another means of unlocking your credentials.
tristan957 11mo ago
If Konsole suits your needs, there is no reason to move to Ghostty. You may find better performance or access to more terminal features, but if those don't move the needle for you, then it doesn't matter. Konsole is well integrated in to KDE.

zadjii 11mo ago

No love for Windows Terminal? I know that linux has a much richer terminal ecosystem, but WT ranks a lot higher than a wide breadth of terminal emulators on linux now. Could anyone have imagined that 10 years ago?

gschizas 11mo 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 https://www.youtube.com/watch?v=8gw0rXPMMPE :) EDIT: I love the easter egg with the names of the developers across the Windows timeline :)
TacticalCoder 11mo ago
[dead]
epolanski 11mo ago
I absolutely love it, it's my personal favorite. Using ghostty on MacOS instead. But I'm no power user.
- bigstrat2003 11mo ago
  I would argue that anyone who uses the terminal enough to have opinions on which one they like best is very much a power user.
  - epolanski 11mo ago
    I don't know, reading around feels like power users are mostly defined but the tons of features they use and miss when switching emulators.
jscyc 11mo 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.

jeffbee 11mo ago

It's interesting that these are rankings, but in some cases the individual points are make or break for a given use case. For example, none of the emulators ranked higher than iTerm2 support Tek 4010 mode, which iTerm2 does support. So that's the one I keep using.

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

electroglyph 11mo ago

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

altairprime 11mo ago
That seems fixable with a pull request to ucs-detect, if one hasn’t already been made.
- electroglyph 11mo ago
  good call, you're right

christophilus 11mo ago

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

ac29 11mo ago
Yep this is my current favorite too. I liked ghostty when I evaluated it, but for some reason it uses an order of magnitude more memory than foot to display a single, empty terminal.
- tristan957 11mo ago
  Ghostty uses GTK + GPU rendering while Foot uses Wayland primitives and CPU rendering.
  - colordrops 11mo ago
    I've seen zero performance issues with foot.
    - tristan957 11mo ago
      My comment was not to imply that Ghostty performed better than Foot. Foot is a great terminal.
colordrops 11mo ago
Foot is the best. Love ctrl-shift-o to open up links
RVuRnvbM2e 11mo ago
I'm quite confused why this article tests foot v1.16.2, which is two years old at this point. The latest version is 1.25.0. By contrast, the tested version of ghostty v1.2.3 is two weeks old.
- aorth 11mo ago

enriquto 11mo ago

The table seems wrong. Xterm supports sixels.

altairprime 11mo ago
You can fix that with a pull request to ucs-detect; for example: https://news.ycombinator.com/item?id=45801452 https://news.ycombinator.com/item?id=45801452
the_gipsy 11mo ago
Only if run with `-ti 340` argument. So in general, it's not there.
omoikane 11mo ago
Same for mintty. I tried `echo "\e[c"` (send device attributes) on mintty 2.8.1 just now and got "4" back ("VT132 with Advanced Video and Graphics").

cb321 11mo ago

`st` used to have a patch set for sixel graphics on its web site. I use an old version all the time to do gnuplots in terminals with nice scrollback. It seems to have been retired in favor of the kitty graphics protocol.

imiric 11mo ago
This[1] is an up-to-date fork with sixel support, and a few other patches. IMO it's unfair to compare barebones `st` with fully-featured terminals. The entire point of `st` is for users to apply their own patches to it, which does make it difficult to compare, since there's no standard version of it. `st` is a pretty great terminal. I switched to `foot` when I migrated to Wayland a few months ago, but not for any practical reasons other than wanting to rely less on Xwayland. [1]: https://github.com/veltza/st-sx https://github.com/veltza/st-sx
- cb321 11mo ago
  I 100% agree `st` is pretty great and comparing bare bones is unfair. Thanks for that link! I suppose I should have provided a link to the variant I use which is https://github.com/bakkeby/st-flexipatch 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.

topaz0 11mo ago

I can't remember the last time I used a non-ascii character in the terminal. I know that's not the case for everyone, and they deserve good terminals too, but it does mean that the criteria measured here have no relevance to my choice of a good terminal for me.

ubercow13 11mo ago
Seems quite hard to avoid - file management such as running "ls" where any filename has any non-ascii character such as a CJK or accented letter - editing any text file in a terminal editor that isn't 100% ascii - viewing/printing any data from any source, such as a log file/the web/'curl'ing something, where any language other than English or non-ascii character is used - using various modern command line tools that insist on printing emojis in their output
- hnlmorg 11mo ago
  > using various modern command line tools that insist on printing emojis in their output Ugh. Unpopular opinion this but I personally find this practice repugnant. Same for when used in git commit messages, CI/CD task names and other such places. It just cheapens the quality of the product in my opinion Graphical characters and symbols like ticks I’m fine with. I have no objection to people wanting to make the terminal pretty. But emojis in software feels like juvenile - like signing a formal letter with your gaming handle.
  - epolanski 11mo ago
    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.
    - pseudalopex 11mo ago
      I want country codes not flags. And check marks do not require emoji. Every emoji I saw in a terminal or Git commit message was worse than alternatives. This included emoji intended for information not fun. Color made them distracting when the wanted information was anything else. A monochrome font could not solve this because most emoji are too complex to display clearly at normal text sizes without color. They were cumbersome to grep. (Uncommon Unicode characters would have this problem also.) Many had unclear meanings. Use emoji in your CLIs if you desire. But make them optional. Opt in ideally.

imiric 11mo ago

> And then my next windmill that I'm looking at is variable-sized text in the terminal. So when I'm catting a markdown file, I want to see the headings big. Is this something people actually want? One of the reasons I enjoy using the terminal is because the text is of a fixed size and monospaced. Even colors and bold text can be distracting at times. I certainly don't want my terminal to render Markdown... I imagine the feature could be disabled, but still. I'm all for improving terminal UIs, but let's not turn them into a web browser.

joouha 11mo ago

I'd find it very useful to be able to query a terminal to see if it has font support for a given list of characters. This would allow TUIs to use recent unicode characters which may not be supported (e.g. Symbols for Legacy Computing), or private use characters (e.g. powerline symbols & font-awesome icons), while falling back to a more universally supported character in terminals that do not support them.

loph 11mo ago

The list does not include DECterm. https://stuff.mit.edu/afs/net/dev/system/pmax_ul3/srvd.74/usr/lib/X11/help/dxterm/Overview 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.)

dgl 11mo ago
xterm does and some others, I posted about this and emojis a while ago: https://dgl.cx/2025/06/can-your-terminal-do-emojis https://dgl.cx/2025/06/can-your-terminal-do-emojis
- altairprime 11mo ago
  (161 comments) https://news.ycombinator.com/item?id=44362272 https://news.ycombinator.com/item?id=44362272
unleaded 11mo ago
strangely enough Windows Terminal supports DECDHL but barely any on Linux do!

tmtvl 11mo ago

Some vaguely related things: - VTTEST <https://invisible-island.net/vttest/vttest.html 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 https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt>.

unleaded 11mo ago

It's interesting that none of the programs commonly known as "terminal emulators" actually emulate a terminal.. we can do that now though. https://zork.net/~st/jottings/Real-VT102-emulation-with-MAME.html https://zork.net/~st/jottings/Real-VT102-emulation-with-MAME... I would avoid doing the PTY thing and instead do this (works on WSL if MAME is the windows version): $ sudo socat TCP-LISTEN:1234,reuseaddr,fork EXEC:"/sbin/agetty -L - 9600 vt102",pty,setsid,ctty,stderr $ mame -nomouse vt102 -rs232 null_modem -bitb socket.localhost:1234 You can do the same thing with a vt220. I've had an idea to try to write a sort of high-level-ish VT220 emulator that pokes and patches the ROMs and the system to let you control it with the mouse, paste and stuff, lets you just doubleclick it to get a terminal, etc... I forgot about that until seeing this. Nobody would use it for more than 5 minutes but it would be funny.

dgl 11mo ago
If MAME could support the VT525 (nearly the last terminal DEC made and unlike the previous DEC models it supports ANSI color) people might use it a bit more. It would be very useful for compatibility testing as there aren't many people with a real VT525! Last I looked someone had dumped the ROMs but there wasn't any support code.
- p_l 11mo ago
  VT5xx was the budget line with limited functionality, that's why only 525 among them supports ANSI color. The only fancy stuff was multisession (TD/SMP if you have all bits to support it) and "desktop accessories" like clock and calculator. The really interesting ones are VT340 variants with ReGIS and full SIXEL graphics
  - dgl 11mo ago
    The VT3xx ones that were color did not support ANSI SGR to set them. I don't think VT5xx was a budget line, it has more escape sequences than the previous ones (including interesting ones like changing cursor shape, which modern terminals implement too). It's more that they never made a graphical version of the VT5xx (this was the early 90s, whether physical VTs made sense anymore is debatable, but terminal graphics likely didn't). VT340 is definitely interesting and if someone were to emulate one that would also be great! (there's been some good research, e.g.: https://github.com/hackerb9/vt340test https://github.com/hackerb9/vt340test, which you might be surprised to learn has been used to make Windows Terminal one of the more conformant terminals...)

sho_hn 11mo ago

Pretty nice to see KDE's Konsole rank really high, especially if you take performance/test elapsed time into account. Considering it's a decades-older workhorse compared to the new star ghostty, not too shabby that it's kept up.

yokljo 11mo ago
Agreed. It's nice to be able to just use the provided terminal when running KDE. It's very customisable and runs plenty fast. I also love being able to right click on Dolphin and tell it to open Konsole in the current folder. Also, I leave infinite scroll back turned on in Konsole and it works really well, swapping out to a file as it gets too much scroll back. Nothing worse than getting errors that I can't read because the terminal discarded them. I have Ctrl+Shift+X bound to clear everything, which I use before running just about any operation.
- jcgl 11mo ago
  > I also love being able to right click on Dolphin and tell it to open Konsole in the current folder. This is a KDE thing; it'll open in whatever terminal you've got configured in Default Applications.
whateveracct 11mo ago
Konsole Just Works
TiredOfLife 11mo ago
Unfortunately Konsole has this feature that each time you switch tabs the maximized window shrinks by a couple of pixels (at least on Steam Deck)

j1elo 11mo ago

Work had me using the Windows Terminal for the first time ever after a life of developing on Linux. I got immediately hooked on the smart Ctrl+C and Ctrl+V (without needing to use Shift like on Linux!) For those not knowing, Windows Terminal uses Ctrl+C to abort the current process (as we'd expect) when nothing is selected, but copies when there is a selection. Similarly, Ctrl+V just pastes. So convenient!

stefanha 11mo ago
In Linux (Wayland) you can copy text from the terminal without pressing Ctrl+C at all. Just select the text. To paste it in another Window, press the middle mouse button. This is called the Primary Selection and is separate from the Clipboard (Ctrl+C/Ctrl+V). IMO the Primary Selection is more convenient than the Clipboard.
- j1elo 11mo ago
  Yeah I know. I missed this for the first couple days, but didn't take much before forgetting it after the change to Windows. (anyway I keep using Linux at home)
- DaSHacka 11mo ago
  Isn't this an X11-ism? I dont believe this is Wayland-specific
- lelandbatey 11mo ago
  This is also a thing in X, not only Wayland.
- pmontra 11mo ago
  That's an X11 thing that Wayland had to reimplement because it's so convenient. The problem is when pasting into the terminal something that another program copied into the clipboard. That's ctrl-shift-c. I thought about remapping copy and paste to their own keys, possibly a single one. Maybe on the number pad, which I never use. Or remapping ctrl-c.

ctippett 11mo ago

I appreciate this analysis is on the state of terminal emulators, but I'm curious how well the integrated terminals that come bundled in code editors/IDEs also perform. For example, where does Zed's integrated terminal fit in the rankings? VS Code (and its derivatives)? JetBrains, Sublime Text?

kartoffelmos 11mo ago
vscode terminal came in at number 32. https://ucs-detect.readthedocs.io/sw_results/vscodeterminal.html#vscodeterminal https://ucs-detect.readthedocs.io/sw_results/vscodeterminal....
- ctippett 11mo ago
  I missed that one!

uvaursi 11mo ago

I still use PuTTY and a MAX232EACwhateverthefuck chip for embedded hardware stuff with a DB9 cable thats been plugged in and out more times than your mom on prom night. Should I switch to something else or just keep on truckin?

shirro 11mo ago

Terminal emulators are caught between emulating terminals and teletypes of the past and implementing new features and unicode is one of the struggles. The way most terminals and wcwidth handle the width of characters sometimes is not correct but preserving behavior is important for compatibility. It is possible that its just not worth trying to handle all unicode perfectly in a terminal. Its pretty good for legacy stuff and sysadmin. We have other ways of doing things remotely like html that might be more appropriate for ZWJ emoji and languages with complicated text shaping/rendering.

kevin_thibedeau 11mo ago
For glyph width, there are codepoints classified as ambiguous width. These are mostly narrow pre-emoji symbols that have been extended with an alternate emoji representation. There's no way to predict what their width will be, even with explicit variation selectors which might just be ignored.
- charcircuit 11mo ago
  The terminal emulator knows what font is being used so it should be possible to predict it.
  - kevin_thibedeau 11mo ago
    The terminal application doesn't know the font. The best you can do is discover ambiguous widths by printing codepoints and checking the change in cursor position. That's a suboptimal experience.
- lifthrasiir 11mo ago
  > These are mostly narrow pre-emoji symbols that have been extended with an alternate emoji representation. Nitpick: this is incorrect. Easy counter-examples would be arrow symbols like →. UAX #11 helpfully explains what is "ambiguous" about those characters: Ambiguous characters occur in East Asian legacy character sets as wide characters, but as narrow (i.e., normal-width) characters in non–East Asian usage. (Examples are the basic Greek and Cyrillic alphabet found in East Asian character sets, but also some of the mathematical symbols.) Private-use characters are considered ambiguous by default, because additional information is required to know whether they should be treated as wide or narrow. In the other words, these characters have been commonly available in both Asian and non-Asian character sets and assigned different widths by them.

deleted 11mo ago

[deleted]

musicale 11mo ago

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

eschatology 11mo ago

While the article title is true (errant is a very specific and concise word), to me it did not convey clear enough that this is just ucs-detect / unicode support (compliance?) ranking. The article title "State of Terminal Emulators in 2025" implied a larger comparison of terminal emulators than just ucs-detect. Personally I also question the practicality or usefulness of this table because why should I care about having "the best unicode support"? Curious, I briefly compared top ranked emulator (ghostty) on how fast it can print 10000 lines and it took 432ms compared to alacritty, ranked 18 (50ms), and Terminal.app, ranked 29 (50ms). If this is the trade-off to have the best unicode support, why should I want it? Why does it matter?

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

ivanjermakov 11mo ago

Unicode support in terminals is kind of a mess for TUI software developers. There is no good way to know how many columns a Unicode character will take, because terminals use different grapheme clustering algorithms. For a text editor I'm making I ended up with: > Unicode support is limited to what common modern terminal emulators support. In Hat, "character" is a Unicode codepoint. So no grapheme clustering, no variation selection, no ZWJs, no terminal emulator-specific logic. As long as every buffer byte is displayed and editable, we're ok. https://github.com/ivanjermakov/hat/blob/master/CONTRIBUTING.md 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/00782dbaee1e1a814cea43c4f837aad2ac9a591e/src/unicode.zig#L63 https://github.com/ivanjermakov/hat/blob/00782dbaee1e1a814ce...

Piraty 11mo ago

a look at terminal emulators https://lwn.net/Articles/749992/ https://lwn.net/Articles/749992/ https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/

sanskarix 11mo ago

[dead]

sanskarix 11mo ago

[dead]

dmaa 11mo ago
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.

dmaa 11mo ago

I used iterm2 for ages, but then somehow defaulted to terminal.app. It is fast and that is basically all i need from a terminal emulator, everything else is taken care of by tmux.

krautburglar 11mo ago
it is also a lot easier on the battery than iterm2

p_l 11mo ago

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

Joker_vD 11mo ago

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

j4_james 11mo ago
Agreed. The only thing that VS-15 is supposed to do is give the emoji a "text presentation", which the spec suggests as "black & white". And every example they show of a text presentation is exactly the same width as the emoji presentation. Changing a character's width from wide to narrow after it has already been output is fraught with problems for a terminal. Imagine trying to write a "narrow" text presentation emoji in the bottom right corner of the screen. You'd think it should fit, but the emoji is received before the VS-15 selector, and that doesn't fit, so the terminal is forced to wrap the text, triggering a scroll of the entire page. By the time the VS-15 arrives, there's no way to undo all of that. And for another example, try using IRM (insert replace mode) to insert a text presentation emoji in the middle of some existing text. If it was really narrow, you'd expect it to insert enough space for just one character, but it actually inserts two spaces, only occupying one of them, and then leaving an unexpected gap. And the more of these "narrow" characters you insert, the bigger the gap becomes. VS-16 changing a text presentation character from narrow to wide doesn't share these problems. And that behaviour is supported by the spec text, which says that emoji should generally have a square aspect ratio. And at one time the East Asian Width spec specifically mentioned VS-16 making narrow characters wide (but said nothing about VS-15 making wide characters narrow).

UltraSane 11mo ago

Why are we still emulating dumb terminals in 2025?

childintime 11mo ago

These terminals properly handle single + double width fonts. But the same thing could work with single + half width fonts, so i,j,l,:,!,.,' and space would fit in half the width. Does anyone know of such a font? I searched but couldn't find any bi-spaced font with full/half width cells. It would not only fit more text on a line, while (probably) also being nearly as pleasing as a proportional font, but it would also still perfectly align indents. I think it could be a great markdown font.

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