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.
Maybe you mean it's too much effort, because I'm sure you could. I was taught touch typing on a QWERTY keyboard in the summer between 6th and 7th grade. Last year I switched to Colemak after nearly 30 years of QWERTY.
Oh I have no doubt that I could but I don't see why since linux already does what I need and I don't see any compelling reason to switch. I was just curious to see what all the hype was about with the new m1 CPUs and give it a shot.
Yes, but specifically in the context of Terminals (as discussed in the original article), it's really convenient to be able send Ctrl-C (break) differently than Cmd-C (copy).
So yes keyboard remapping is an option. But there's just differences you can't remap because of the extra meta keys on Mac (and I guess on Windows too, with the Copilot or Start keys in play).
> it's really convenient to be able send Ctrl-C (break) differently than Cmd-C (copy)
Right, and even on Linux you can do it by using the four-fifths forgotten CUA shortcut Ctrl-Insert for copy (and Shift-Insert for paste.) Although I'll admit to using Ctrl-Shift-C/V most of the time.
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 feel the opposite, the near-thumb position for the most used modifier is a godsend vs pinky strain.
Ctrl in caps lock is debatably better but that key is arguably better used for esc in vim setups (or the harder to setup “ctrl if held, esc if tapped”).
cmd is brilliant. I have to shift my entire hand downward a little to hit ctr+c/ctrl-v, and make a pinkie-stretch that I can feel straining my hand. Cmd+c/v keeps three fingers on the home row, and involves just a slide-over of the thumb by maybe a centimeter. It's great.
caps-as-an-extra-ctrl helps with all of that, but leaves you with the problem of overlapping shortcuts in the terminal. Cmd also fixes that.
I hate how hard it is to get anything remotely like it working in Linux. All the solutions are partial and very janky.
It’s a sentiment I’ve expressed many times here on HN, but I’d love to see a DE and matching set of apps designed to embrace Mac-like UX, including meta-based key shortcuts. It being like that out of the box instead of requiring a patchwork of spotty config changes and hacks brings massive value.
On all my machines I remap Caps Lock to Control, and since I still use Control from time to time under macOS, I have muscle memory for it, and so switching between Control/Command dominance is low friction.
Control in its typical position however drives me crazy.
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.
There's always Ctrl+Insert for copy and Shift+Insert for paste. I know that there's some laptops lacking an insert key, which is terrible, but for keyboard with an insert key the Ctrl/Shift + Insert combos are useful at times.
Especially because one does not have to push three keys with the same hand, which is not nice to tendons. I think I did that for a while time ago, then forgot about it. Thanks.
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]
You can unbind the Ctrl+V keymapping if you want, and it behaves as expected in emacs -nw at least. (There's a Ctrl+Shift+V binding set up by default, same as many Unix terminal emulators, so you won't miss out.)
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.
It depends on the semantics of "everyone" and "knows". The X11 selection bindings predate CUA clipboard usage by a few years, actually. But in any case, the contention was that they were simpler, not that they are standard. And they aren't.
Yeah, that slows down typing a lot. Luckily people on a laptop can use the touchpad which lies just below the space bar. I have a laptop with physical keys around the touchpad so I even have a button to paste. No need to tap, double tap, etc. I think that I never used a mouse in the last 20 years.
You can cut/paste within your editor just fine. The subject at hand is window-system level clipboard/selection interaction, and in particular the presence of standard key bindings for them in various environments. While some terminal and editor apps do have keyboard bindings that interact with the OS clipboard, none are standard.
Basically, yeah: you had to use the mouse to select it in the first place. Using the mouse to paste it is easier, not harder.
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
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, which you might be surprised to learn has been used to make Windows Terminal one of the more conformant terminals...)
The references to "budget line" were from contemporary sources, and that it was heavily reduced in cost - while terminal sequences were more of "simple matter of programming" ;-) My understanding that some of the features like changing cursor shape were related to the rudimentary custom font feature which was retained from more expensive 3xx line and which accepted IIRC sixel-encoded bitmap fonts.
Funnily enough, the one VT510 I had for some time actually came from a VHS rental place that for reasons unknown to me ran Blockbuster Video customized VAX 6.1 on Alpha (which I also grabbed). BBV was not very well known in Poland, but this specific machine had unwiped disks and logs showing it was used from 1996 to 2000, then it was found lying in a corner when a moving service was asked to clean out a location after a tenant that came in after the video rental.
There was probably a DECserver missing somewhere in the pile before I got my hands on it ;)
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.)
There are a ton of people who _immediately_ open tmux/zellij/etc. when they're doing anything in the terminal. This means you use its backscroll and search feature, and you wouldn't notice.
@mitchellh seems to rely on the Ghostty feature to dump scrollback to a file, and edit/search over that.
I found it a bit too inconvenient when using remote systems frequently, though. (If I'm missing a trick, I'd love to use Ghostty! But I'm just not a fan of multiplexers.)
My use cases are trying to find the one test that failed out of my suite and finding a specific log print when my app is running. Yes, there are other ways to do both of these. Having scrollback search in the terminal is a very convenient option though.
Honestly, I had never even heard of it before this very thread. It doesn't seem all that useful to me, but I don't truthfully know how much or how little I would use it in practice.
> To be completely clear, it’s not on the “IMMEDIATE” roadmap (as noted in the prior comment). It’s absolutely on the roadmap and I even already started some it in a branch. But as a passion project, we prioritize working on whatever we want and this isn’t currently the priority. It’s high on the list but not like.. next release (“immediate”) priority at the time of this comment.
I mean I can respect that, personally it isn't as a big of deal with me so I use ghostty on my mac but I would still think that I would advocate ghostty only after disclosing this to anyone to be really honest.
The first time I went through the theme picker, I was tickled to see a theme I had made years ago included. Realized later it was due to it including all of the themes from iTerm2 Color Schemes automatically.
It made for a more fun first experience with a terminal emulator than I expected to have.
Same here. Any replacement I moved to needed to have content centering, where the margin around the cells is equal in both dimensions when the cells don't fit perfectly into the window. Kinda crazy that it's not a feature in a lot of terminals I checked over the years. I wouldn't even consider myself OCD, but it drove me nuts until I found a terminal that let me do it.
I'm always running tmux so it's not typically a feature I look for, but as you mention it doesn't seem to trigger a find for terminal scrollback. Wezterm doesn't do this either so maybe that's an iTerm thing. I always assume Ctrl keybindings will trigger emacs mode shortcuts in the tty.
I would love to use tmux. I have used yazi in the past and I really liked it but I was barely using it to its fullest potential.
I think I have "skill issue" regarding tmux and I used to use hyprland (recently went to niri) and I just always preferred opening up another terminal I used to use (which was foot back when I was using my own config and it was alacritty on cachy/ idk what was on omarchy for the time I was on omarchy but I don't like omarchy)
Is there actually a way to fix this skill issue, like I want something so simple in start that I just run it and forget and still get decent amount of benefits?
tmux fits my personal use case better so I'll tell you why I use tmux and then if that resonates with you, then you might get value from that as well.
- It's generally bundled on most distros, or available for install in most default repositories.
- tmux sessions are available over ssh, so if I can continue where I left off over ssh (this is probably my main use case).
- I can full screen my terminal instead of having multiple terminals, and split in tmux. I usually split vim buffers, but then keep a terminal split beside it or in another tmux window.
- It's keyboard-driven, and universal across different window managers. Even if I switch from MacOS to Windows or to an X11 distro, tmux will still have the same keybinds using the same configuration language. I can also use vim keys to navigate the scrollback history.
- Its config language is simple enough for the modifications I personally need. I haven't felt that I need to learn the syntax beyond the basics.
- Knowing tmux is also a helpful skill for managing servers, which I do from time to time (my raspberry pi is still running a tmux session from when I last rebooted it).
it may happen that you just don't need it - the same way not everyone need to use vim/neovim.
without tmux/screen though, it's much harder, even less reliable, to work over ssh, so it becomes natural need for such sort of tools.
Say I use screen and later tmux since I believe ~ 2010 but not using "advanced" features like "panes" and screen splitting every month, most of the time for me it's just switching between windows in session and different sessions (not that often) and that's all.
As a helper, for some projects, I do use predefined layouts (say first 4 windows opens with inventory dir, other 2 with root folder of ansible repo) so on, but need this also not very often, like when laptop reboots (which is every ~ 3 week on Win11 nowdays)
Apple Terminal is a lot like Internet Explorer in the 00s: for power users it’s only purpose is an interface to install something else which doesn’t suck.
As a decrepit old {COMMO} power user, anything that doesn’t give me fully integrated scripting with expect/switch/dialog and a popup script editor, honestly hasn’t been worth investing in further. So I’ve been on Linux console, Putty, and macOS Terminal ever since.
My terminal.app color scheme uses P3 colors on 7% gray rather than the usual sRGB colors so that I can use an OKLCH equidistant palette, and I make extensive use of shift-cmd-up to select and copy “the previous command’s output”. I considered switching for 24-bit color but ultimately I prefer not having to learn a new “rudimentary” app that’s deficient versus my nostalgia just like all the others, and it drastically reduces my stress level when working on other people’s devices that I am proficient in working with an OEM environment.
I occasionally use tabs but for the most part I prefer windows, so that I can drag them around and over/underlapped with other work I’m doing in my GUI. Not a big fan of screen and tmux except as their limited value to me in mitigating ssh disconnects when that’s a concern.
Perhaps your definition of power user is limited to uses aligned with your own?
> Terminal.app does suck but if you’re happy in it
Clarification: As noted above, Terminal.app is indistinguishably suck from all the rest in the areas that are materially important to me, so no meaningful gain in happiness exists with any current alternative. I enjoy one of the specific features it offers but I’d give that up the instant a relevant-to-me improvement over the status quo was available. Perhaps someday.
I would probably have to make a video, honestly. Have considered it. Usage faded out years before screen recording was accessible. I’m going to be late for class but I can’t allow that article to stand unsupported by story tidbits.
The built-in editor for all files had two modes, line-based and character based. In edit (char) mode, you edited the text file as usual. In line (command) mode, you selected lines and hit Return on them to begin execution there.
Commands were wrapped in curly braces; non-wrapped text was ignored.
The built-in phone directory was just a macro file with a dedicated keystroke; so you could structure and annotate it however you liked, and navigate it with search or with line-based mode up/down/pgup/pgdn as one would expect. Each entry was something like {dial 472627} {user x} {pass y} {ifca {goto :autologin_wwiv}} {end} with whatever niceties you enjoyed outside the curly braces.
It understood {gets} and {puts} from the modem tty (I don’t remember the actual command names) and it had conditional logic and substring index stuff.
If you needed human input, you could throw a {dialog} and get it, acting according to the result.
In modern parlance, imagine if your terminal emulator had ansible playbook support embedded into it and pressing alt-E popped up an editor for the playbook that let you start playback from any point in the script, JMP/GOTO-style.
You can see an example playbook at https://ftpmirror.your.org/pub/misc/dos/cavebbs/The%20Cave%2... inside PWRMC30S.ZIP. Read everything that isn’t a .MAC file first so that you know where to start reading. POWER.MAC is the main attraction; 53k of playbook macros serving as bionic assistance to TradeWars players.
My own archives are currently probably-lost unless I get very lucky someday, or else I’d share my own archive of playbooks built up over five years to auto-dial and auto-QWK hundreds of local BBSes for two-way mailing list packets.
I think of it every time I see 'ansible' come up, because the ability to create and run what everyone calls 'playbooks' now should have beeen integrated into the terminal like it was back in the 80s over dialup. I'm all for being able to git commit the resulting script (they’re just text files!) but being able to launch a playbook and halt it and repair it and resume was, like.
It's what I've used for years and it's entirely fine for me.
For a long time I installed iterm2 because "that's what you do" but one day I realized I was suffering a little wasted disk space, slightly slower start-up, and slightly worse input latency, for... no reason, because I didn't do anything with it that Terminal.app couldn't do.
25 years on unixy operating systems. Spend tons of time in the terminal.
I used IE back in the 00s (up until Chrome came out), and I certainly was a power user. I liked it just fine. I think that it's a matter of personal preference rather than something sucking (or not).
I appreciate this analysis is on the state of terminal emulators, but I'm curious how well the integrated terminals that come bundled in code editors/IDEs also perform. For example, where does Zed's integrated terminal fit in the rankings? VS Code (and its derivatives)? JetBrains, Sublime Text?
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.
There are preexisting narrow symbols that were given a new emoji presentation in later standards rather than assigning a new codepoint. Text rendering engines vary on which form is the default. VTE had an option to set the preference. This can be very annoying when some arrows get the new emoji form but others in their cohort stay as narrow glyphs.
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.
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.
All depends on what you're doing. When I worked in computational linguistics of languages that don't use ASCII (or European "accented" characters), I was very concerned with the display of non-ASCII Unicode scripts: Arabic, Devanagari, Thaana, Tamil, Chinese, even at one point Cambodian (which was extremely hard to render, even in XeLaTeX--it's improved since then). But at the moment, accented European characters are all I need.
> 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.
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.
Sixel came earlier, and already fulfilled the basic requirement of "put
pixels on screen in a single well-defined format" (something not even
iTerm2's protocol does.)
Kitty is a lot more complex: it accepts five different encodings, has three
different ways to load the data, supports animations, etc. So it's no
wonder only a few terminal developers had time to implement it.
> Now if the Kitty image protocol is so great and the Sixel stuff is so bad, why is it only used in Kitty and Ghostty?
Images as in "pictures" or is that something else? I'm using Alacritty, and I don't think I've once thought "I need to see this image inside the terminal" and I do deal with images and frames from videos a lot. Probably if I saw it being added to Alacritty I'd think it was adding unnecessary bloat, so I wouldn't be surprised not every terminal is rushing to implement it.
Or I completely misunderstand what you're talking about.
I run Kitty and use this feature regularly. Most of the time, I rely on it within Yazi [1], a TUI file manager, but I can also display plots within the Julia REPL, thanks to the KittyTerminalImages.jl package [2]. It's even more crucial when I'm navigating a remote directory and need to check an image file, as I usually have timg [3] installed on those servers. Once you discover how valuable this is, it becomes a permanent part of your workflow.
Definitely. I use KittyTerminalImages.jl often, and also the image.nvim plugin for embedding images into a Markdown or other buffer in Neovim: https://github.com/3rd/image.nvim
I have to say, (caveat, I have not tried any of these yet) that I am intrigued by all these features like graphics being added to terminals. It feel like exploring an alternate timeline 1990s where the GUI “lost” — of course in the absence of a successful Windows and Macintosh, terminals would have naturally gained these graphical abilities 30 years ago.
It’s pretty nice to ssh into a remote host and plot some data there without needing either X forwarding, or dumping to files and rsync’ing, or similar workarounds.
The alacritty maintainers reject any image protocols as unnecessary. I am fond of images in terminals, but I gotta say that I respect their decision, very good call. Not every terminal emulator should do the same.
Viewing an image in a terminal can be really handy for debugging ML systems that use images or bitmaps. You can also paste images directly into claude code as context.
Once while working on a daemon that did both ML and DSP on live audio I added the ability to play sounds and display spectrographs of in-memory audio data at various points of the internal pipeline to debug an issue that would have been difficult otherwise. Way quicker than dumping WAV files to view externally.
I can confirm that I just do it over ssh fine all the time -- gnuplot, img2sixel as an "image-cat", etc. (`st` with patches to add sixel support as discussed in various places in these comments.)
IMO none of them are particularly useful. Sixels is hilariously inefficient. Kitty is slightly better because you can send data as PNG, but ... you have to send image data as PNG!
I wish there was a high performance way of remoting graphics over SSH. How cool would it be if you could SSH to a remote machine and it just showed you the remote desktop in the terminal itself? No messing around with port forwarding, weird X servers, etc.
I think probably that requires a full fat video codec like H.264 to work well though. Or maybe RDP?
Probably too many GUI naysayers and "What's wrong with remote X?" for this to ever happen though.
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.
Yeah I want all of those. Only the third one really works at the moment but it's also the least useful. The second one I think would be the most transformative because then all the TUI apps people use like htop, ncdu and so on can have decent graphics.
At that point you're really better off using some other remoting protocol instead of trying to tunnel it all over a terminal session. There's nothing left of the original terminal.
There is though - the ssh authentication and connection is already handled, and I'm already in a terminal. When I quit the app or session I'm back in the terminal.
If it worked it would greatly reduce the hassle.
Think about all the TUI apps that exist. They're useful because they're convenient when working in a terminal, not because they look like shit.
If I want to view an image file on a remote machine, and all I have is ssh... I just connect to that machine with filezilla and click on whatever files I want. I can even open files that aren't PNG! Even files that aren't even images at all. Mindblowing.
A terminal with in-band graphics primitives is called an RDP client.
We've had graphics terminals since RIP BBS's and even before that. If they were actually useful enough to be worth the bother, then we'd all have been using them all along and there wouldn't be posts like this.
It's not a case of there's this awesome idea that just for some reason no one knows about. No, it's just not that awesome of an idea. It's not harmful so it doesn't bother me that most xterms support tektronix graphics, it's just a gimmick of no real value. It's a solution to no problem.
Don't believe me? When was the last time you used passthrough printing? Or saw it being used even in some place where they do actually need to print? The terminals all still support it. It's just a thing that you don't need to do in-band in a tty, and today there is no reason to bother doing it that way even though you could. It's not better and does not solve a problem.
I have yet to use it though because Wayland still doesn't work properly for me (it doesn't restore the desktop properly after sleep) so I'm still on X11... without compositing... because KWin's compositor causes random freezes.
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.
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.
`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.
Maybe you mean it's too much effort, because I'm sure you could. I was taught touch typing on a QWERTY keyboard in the summer between 6th and 7th grade. Last year I switched to Colemak after nearly 30 years of QWERTY.
Oh I have no doubt that I could but I don't see why since linux already does what I need and I don't see any compelling reason to switch. I was just curious to see what all the hype was about with the new m1 CPUs and give it a shot.
It's easy and reasonably quick to set up key remapping (via Karabiner).
Yes, but specifically in the context of Terminals (as discussed in the original article), it's really convenient to be able send Ctrl-C (break) differently than Cmd-C (copy).
So yes keyboard remapping is an option. But there's just differences you can't remap because of the extra meta keys on Mac (and I guess on Windows too, with the Copilot or Start keys in play).
> it's really convenient to be able send Ctrl-C (break) differently than Cmd-C (copy)
Right, and even on Linux you can do it by using the four-fifths forgotten CUA shortcut Ctrl-Insert for copy (and Shift-Insert for paste.) Although I'll admit to using Ctrl-Shift-C/V most of the time.
My keyboard doesn't even have an insert key.
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.
What do you dislike about cmd placement?
I feel the opposite, the near-thumb position for the most used modifier is a godsend vs pinky strain.
Ctrl in caps lock is debatably better but that key is arguably better used for esc in vim setups (or the harder to setup “ctrl if held, esc if tapped”).
cmd is brilliant. I have to shift my entire hand downward a little to hit ctr+c/ctrl-v, and make a pinkie-stretch that I can feel straining my hand. Cmd+c/v keeps three fingers on the home row, and involves just a slide-over of the thumb by maybe a centimeter. It's great.
caps-as-an-extra-ctrl helps with all of that, but leaves you with the problem of overlapping shortcuts in the terminal. Cmd also fixes that.
I hate how hard it is to get anything remotely like it working in Linux. All the solutions are partial and very janky.
It’s a sentiment I’ve expressed many times here on HN, but I’d love to see a DE and matching set of apps designed to embrace Mac-like UX, including meta-based key shortcuts. It being like that out of the box instead of requiring a patchwork of spotty config changes and hacks brings massive value.
This is the closest thing I know, not ideal but decent:
https://github.com/RedBearAK/Toshy
On all my machines I remap Caps Lock to Control, and since I still use Control from time to time under macOS, I have muscle memory for it, and so switching between Control/Command dominance is low friction.
Control in its typical position however drives me crazy.
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!
Ooh, seconded, will try right away.
[EDIT]: so ... tried it ... very, very nice BUT:
what of CTRL-V ???
You can do the same with ctrl+v, just use paste_from_clipboard
> You can do the same with ctrl+v, just use paste_from_clipboard
Yeah, but CTRL+V is actually used e.g. in VIM.
And I can't see a way for ghostty to "guess" what to do based on context like it does in the case something is selected.
Sorry, should have explained better.
Hope Kovid Goyal gets inspired by this
Kitty also has it, I didn't know prior to today
https://sw.kovidgoyal.net/kitty/conf/#clipboard
fantastic!
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.
There's always Ctrl+Insert for copy and Shift+Insert for paste. I know that there's some laptops lacking an insert key, which is terrible, but for keyboard with an insert key the Ctrl/Shift + Insert combos are useful at times.
Especially because one does not have to push three keys with the same hand, which is not nice to tendons. I think I did that for a while time ago, then forgot about it. Thanks.
I always use the opposite modifier key(s) (e.g. right control + a), which I was told to do when I learned to type Dvorak; but you're welcome.
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.
You can unbind the Ctrl+V keymapping if you want, and it behaves as expected in emacs -nw at least. (There's a Ctrl+Shift+V binding set up by default, same as many Unix terminal emulators, so you won't miss out.)
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) ?
Yes, of course I can. I have a separate binding in my tmux config to copy to the clipboard.
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.
It depends on the semantics of "everyone" and "knows". The X11 selection bindings predate CUA clipboard usage by a few years, actually. But in any case, the contention was that they were simpler, not that they are standard. And they aren't.
So now we are moving away from Keyboard only Vim/Terminal thing to mouse for pasting?
Yeah, that slows down typing a lot. Luckily people on a laptop can use the touchpad which lies just below the space bar. I have a laptop with physical keys around the touchpad so I even have a button to paste. No need to tap, double tap, etc. I think that I never used a mouse in the last 20 years.
You can cut/paste within your editor just fine. The subject at hand is window-system level clipboard/selection interaction, and in particular the presence of standard key bindings for them in various environments. While some terminal and editor apps do have keyboard bindings that interact with the OS clipboard, none are standard.
Basically, yeah: you had to use the mouse to select it in the first place. Using the mouse to paste it is easier, not harder.
I can hit the middle click for my Trackpoint without leaving the keyboard :3
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
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, which you might be surprised to learn has been used to make Windows Terminal one of the more conformant terminals...)
The references to "budget line" were from contemporary sources, and that it was heavily reduced in cost - while terminal sequences were more of "simple matter of programming" ;-) My understanding that some of the features like changing cursor shape were related to the rudimentary custom font feature which was retained from more expensive 3xx line and which accepted IIRC sixel-encoded bitmap fonts.
Funnily enough, the one VT510 I had for some time actually came from a VHS rental place that for reasons unknown to me ran Blockbuster Video customized VAX 6.1 on Alpha (which I also grabbed). BBV was not very well known in Poland, but this specific machine had unwiped disks and logs showing it was used from 1996 to 2000, then it was found lying in a corner when a moving service was asked to clean out a location after a tenant that came in after the video rental.
There was probably a DECserver missing somewhere in the pile before I got my hands on it ;)
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.
There are a ton of people who _immediately_ open tmux/zellij/etc. when they're doing anything in the terminal. This means you use its backscroll and search feature, and you wouldn't notice.
@mitchellh seems to rely on the Ghostty feature to dump scrollback to a file, and edit/search over that.
I found it a bit too inconvenient when using remote systems frequently, though. (If I'm missing a trick, I'd love to use Ghostty! But I'm just not a fan of multiplexers.)
I’ve never used scrollback search, and it was a discovery for me that there’s a contingent that are very vocal in their demands for scrollback search.
I can see why someone would feel attached to this feature though.
Mostly I’m looking forward to seeing it implemented so I can stop reading complaints about this being missing in every thread about ghostty!
My use cases are trying to find the one test that failed out of my suite and finding a specific log print when my app is running. Yes, there are other ways to do both of these. Having scrollback search in the terminal is a very convenient option though.
I wish they didn’t lock the GitHub issue so that we could see how many thousands more reactions it would get.
I use ctrl+R for search that way I'm not dependent of a terminal emulator features and can get to work even on random computers.
https://www.gnu.org/software/bash/manual/bash.html#index-rev...
I think most people that want this feature want to be able to search through terminal output, not the commands they've previously used.
Honestly, I had never even heard of it before this very thread. It doesn't seem all that useful to me, but I don't truthfully know how much or how little I would use it in practice.
Same here. What I think I’d like more is the ability to open the most recent command output in $EDITOR.
Relevant GitHub issue: https://github.com/ghostty-org/ghostty/issues/189
> To be completely clear, it’s not on the “IMMEDIATE” roadmap (as noted in the prior comment). It’s absolutely on the roadmap and I even already started some it in a branch. But as a passion project, we prioritize working on whatever we want and this isn’t currently the priority. It’s high on the list but not like.. next release (“immediate”) priority at the time of this comment.
I mean I can respect that, personally it isn't as a big of deal with me so I use ghostty on my mac but I would still think that I would advocate ghostty only after disclosing this to anyone to be really honest.
It's planned for 1.3 in March https://ghostty.org/docs/install/release-notes/1-2-0#roadmap
The first time I went through the theme picker, I was tickled to see a theme I had made years ago included. Realized later it was due to it including all of the themes from iTerm2 Color Schemes automatically.
It made for a more fun first experience with a terminal emulator than I expected to have.
Same here. Any replacement I moved to needed to have content centering, where the margin around the cells is equal in both dimensions when the cells don't fit perfectly into the window. Kinda crazy that it's not a feature in a lot of terminals I checked over the years. I wouldn't even consider myself OCD, but it drove me nuts until I found a terminal that let me do it.
I've always wanted to like Alacritty but they've had an open issue to support ligatures since 2017 and they're not in a rush to implement them.
Now the only feature I need in Ghostty is Windows support.
> Now the only feature I need in Ghostty is Windows support.
I use ghostty on my mac but have you forgot about ctrl + f to find things support in ghostty (I don't think it has ctrl f support iirc right?)
I'm always running tmux so it's not typically a feature I look for, but as you mention it doesn't seem to trigger a find for terminal scrollback. Wezterm doesn't do this either so maybe that's an iTerm thing. I always assume Ctrl keybindings will trigger emacs mode shortcuts in the tty.
Update: Windows Terminal doesn't do it either.
Ctrl+Shift+F on my Windows Terminal - don't remember, have I've adjusted it or it's default behavior
I see in config file, actions { "id": "User.find", "keys": "ctrl+shift+f" },
so probably I did
I would love to use tmux. I have used yazi in the past and I really liked it but I was barely using it to its fullest potential.
I think I have "skill issue" regarding tmux and I used to use hyprland (recently went to niri) and I just always preferred opening up another terminal I used to use (which was foot back when I was using my own config and it was alacritty on cachy/ idk what was on omarchy for the time I was on omarchy but I don't like omarchy)
Is there actually a way to fix this skill issue, like I want something so simple in start that I just run it and forget and still get decent amount of benefits?
tmux fits my personal use case better so I'll tell you why I use tmux and then if that resonates with you, then you might get value from that as well.
- It's generally bundled on most distros, or available for install in most default repositories.
- tmux sessions are available over ssh, so if I can continue where I left off over ssh (this is probably my main use case).
- I can full screen my terminal instead of having multiple terminals, and split in tmux. I usually split vim buffers, but then keep a terminal split beside it or in another tmux window.
- It's keyboard-driven, and universal across different window managers. Even if I switch from MacOS to Windows or to an X11 distro, tmux will still have the same keybinds using the same configuration language. I can also use vim keys to navigate the scrollback history.
- Its config language is simple enough for the modifications I personally need. I haven't felt that I need to learn the syntax beyond the basics.
- Knowing tmux is also a helpful skill for managing servers, which I do from time to time (my raspberry pi is still running a tmux session from when I last rebooted it).
it may happen that you just don't need it - the same way not everyone need to use vim/neovim.
without tmux/screen though, it's much harder, even less reliable, to work over ssh, so it becomes natural need for such sort of tools.
Say I use screen and later tmux since I believe ~ 2010 but not using "advanced" features like "panes" and screen splitting every month, most of the time for me it's just switching between windows in session and different sessions (not that often) and that's all.
As a helper, for some projects, I do use predefined layouts (say first 4 windows opens with inventory dir, other 2 with root folder of ansible repo) so on, but need this also not very often, like when laptop reboots (which is every ~ 3 week on Win11 nowdays)
* use a prepackaged tmux config that makes it look nice and smooths out rough edges
* Spend some time learning keybindings and commands. Just an hour or two should be enough.
* Learn about the top plugins and install them. There's a plugin that saves and restores your session, I forget the name, but it's great
* If you use vim, set up both vim and tmux with the right plugins so that the same keybindings navigate across both vim and tmux splits seemlessly.
I thought built in theme pickers were the norm…?
Lol, mb, but I don't believe that's the case for Alacritty. As for the Apple Terminal, it is not great
Apple Terminal is a lot like Internet Explorer in the 00s: for power users it’s only purpose is an interface to install something else which doesn’t suck.
As a decrepit old {COMMO} power user, anything that doesn’t give me fully integrated scripting with expect/switch/dialog and a popup script editor, honestly hasn’t been worth investing in further. So I’ve been on Linux console, Putty, and macOS Terminal ever since.
My terminal.app color scheme uses P3 colors on 7% gray rather than the usual sRGB colors so that I can use an OKLCH equidistant palette, and I make extensive use of shift-cmd-up to select and copy “the previous command’s output”. I considered switching for 24-bit color but ultimately I prefer not having to learn a new “rudimentary” app that’s deficient versus my nostalgia just like all the others, and it drastically reduces my stress level when working on other people’s devices that I am proficient in working with an OEM environment.
I occasionally use tabs but for the most part I prefer windows, so that I can drag them around and over/underlapped with other work I’m doing in my GUI. Not a big fan of screen and tmux except as their limited value to me in mitigating ssh disconnects when that’s a concern.
Perhaps your definition of power user is limited to uses aligned with your own?
> Perhaps your definition of power user is limited to uses aligned with your own?
I was clearly being flippant. Terminal.app does suck but if you’re happy in it then I’m not going to judge.
For what it’s worth, I cut my teeth on very limited terminals of the 80s and 90s too.
But I ended up writing my own terminal emulator because I wasn’t entirely happy with any of the options available these days.
> Terminal.app does suck but if you’re happy in it
Clarification: As noted above, Terminal.app is indistinguishably suck from all the rest in the areas that are materially important to me, so no meaningful gain in happiness exists with any current alternative. I enjoy one of the specific features it offers but I’d give that up the instant a relevant-to-me improvement over the status quo was available. Perhaps someday.
Where could I learn more of COMMO? How do current terminal emulators fall short? Wikipedia's article was minimal.[1]
[1] https://en.wikipedia.org/wiki/Commo
I would probably have to make a video, honestly. Have considered it. Usage faded out years before screen recording was accessible. I’m going to be late for class but I can’t allow that article to stand unsupported by story tidbits.
The built-in editor for all files had two modes, line-based and character based. In edit (char) mode, you edited the text file as usual. In line (command) mode, you selected lines and hit Return on them to begin execution there.
Commands were wrapped in curly braces; non-wrapped text was ignored.
The built-in phone directory was just a macro file with a dedicated keystroke; so you could structure and annotate it however you liked, and navigate it with search or with line-based mode up/down/pgup/pgdn as one would expect. Each entry was something like {dial 472627} {user x} {pass y} {ifca {goto :autologin_wwiv}} {end} with whatever niceties you enjoyed outside the curly braces.
It understood {gets} and {puts} from the modem tty (I don’t remember the actual command names) and it had conditional logic and substring index stuff.
If you needed human input, you could throw a {dialog} and get it, acting according to the result.
In modern parlance, imagine if your terminal emulator had ansible playbook support embedded into it and pressing alt-E popped up an editor for the playbook that let you start playback from any point in the script, JMP/GOTO-style.
You can see an example playbook at https://ftpmirror.your.org/pub/misc/dos/cavebbs/The%20Cave%2... inside PWRMC30S.ZIP. Read everything that isn’t a .MAC file first so that you know where to start reading. POWER.MAC is the main attraction; 53k of playbook macros serving as bionic assistance to TradeWars players.
My own archives are currently probably-lost unless I get very lucky someday, or else I’d share my own archive of playbooks built up over five years to auto-dial and auto-QWK hundreds of local BBSes for two-way mailing list packets.
Oh wow, I haven't thought of COMMO in decades.
I think of it every time I see 'ansible' come up, because the ability to create and run what everyone calls 'playbooks' now should have beeen integrated into the terminal like it was back in the 80s over dialup. I'm all for being able to git commit the resulting script (they’re just text files!) but being able to launch a playbook and halt it and repair it and resume was, like.
Sigh.
It's what I've used for years and it's entirely fine for me.
For a long time I installed iterm2 because "that's what you do" but one day I realized I was suffering a little wasted disk space, slightly slower start-up, and slightly worse input latency, for... no reason, because I didn't do anything with it that Terminal.app couldn't do.
25 years on unixy operating systems. Spend tons of time in the terminal.
I used IE back in the 00s (up until Chrome came out), and I certainly was a power user. I liked it just fine. I think that it's a matter of personal preference rather than something sucking (or not).
I was clearly being flippant. But IE definitely sucked.
The theme picker in Ghostty is above and beyond anything I’ve ever seen in a terminal.
Why?
Holy crap you’re right. I just found that and it’s amazing
I appreciate this analysis is on the state of terminal emulators, but I'm curious how well the integrated terminals that come bundled in code editors/IDEs also perform. For example, where does Zed's integrated terminal fit in the rankings? VS Code (and its derivatives)? JetBrains, Sublime Text?
vscode terminal came in at number 32.
https://ucs-detect.readthedocs.io/sw_results/vscodeterminal....
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.
There are preexisting narrow symbols that were given a new emoji presentation in later standards rather than assigning a new codepoint. Text rendering engines vary on which form is the default. VTE had an option to set the preference. This can be very annoying when some arrows get the new emoji form but others in their cohort stay as narrow glyphs.
The terminal emulator knows what font is being used so it should be possible to predict it.
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.
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!).
Similarly kitty is at 0.44.0 [0], zutty at 0.16.0 [1]
0.https://github.com/kovidgoyal/kitty/releases/tag/v0.44.0
1. https://git.hq.sig7.se/zutty.git
Yep this is my current favorite too. I liked ghostty when I evaluated it, but for some reason it uses an order of magnitude more memory than foot to display a single, empty terminal.
Ghostty uses GTK + GPU rendering while Foot uses Wayland primitives and CPU rendering.
I've seen zero performance issues with foot.
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.
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.
[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.
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.
All depends on what you're doing. When I worked in computational linguistics of languages that don't use ASCII (or European "accented" characters), I was very concerned with the display of non-ASCII Unicode scripts: Arabic, Devanagari, Thaana, Tamil, Chinese, even at one point Cambodian (which was extremely hard to render, even in XeLaTeX--it's improved since then). But at the moment, accented European characters are all I need.
> using various modern command line tools that insist on printing emojis in their output
Ugh. Unpopular opinion this but I personally find this practice repugnant. Same for when used in git commit messages, CI/CD task names and other such places. It just cheapens the quality of the product in my opinion
Graphical characters and symbols like ticks I’m fine with. I have no objection to people wanting to make the terminal pretty. But emojis in software feels like juvenile - like signing a formal letter with your gaming handle.
Emojis are useful as visual indicators, there's anything from flags to check marks in them.
They can be super helpful to decorate CLI output.
If it feels juvenile but is helpful (as in many cases is) good.
Sure, some CLIs may over do with rockets and such, but any tools can misused.
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.
Unicode can be useful. The emoji subset generally are not.
IMO emojis have no business in any form of text. It just doesn't belong.
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
Definitely. I use KittyTerminalImages.jl often, and also the image.nvim plugin for embedding images into a Markdown or other buffer in Neovim: https://github.com/3rd/image.nvim
I have to say, (caveat, I have not tried any of these yet) that I am intrigued by all these features like graphics being added to terminals. It feel like exploring an alternate timeline 1990s where the GUI “lost” — of course in the absence of a successful Windows and Macintosh, terminals would have naturally gained these graphical abilities 30 years ago.
That alternate timeline started in 1982 with the Blit terminal. [0] It was a GUI made of overlapping terminals that had a serial graphics protocol.
[0] https://www.osnews.com/story/26315/blit-a-multitasking-windo...
It’s pretty nice to ssh into a remote host and plot some data there without needing either X forwarding, or dumping to files and rsync’ing, or similar workarounds.
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.
I didn't know, but I'm happy to hear we seemingly are aligned regardless :) Thanks for the additional context!
Viewing an image in a terminal can be really handy for debugging ML systems that use images or bitmaps. You can also paste images directly into claude code as context.
Once while working on a daemon that did both ML and DSP on live audio I added the ability to play sounds and display spectrographs of in-memory audio data at various points of the internal pipeline to debug an issue that would have been difficult otherwise. Way quicker than dumping WAV files to view externally.
I'm not particularly fond of displaying images on the terminal in ways that would resemble a GUI.
That said, augmenting a shell-based workflow with tidbits such as this had me sold:
https://xcancel.com/thingskatedid/status/1316074032379248640...
https://xcancel.com/thingskatedid/status/1316075850580652032...
To achieve that, either Sixel or Kitty protocol is fine. IIRC Sixel works over SSH without any fuss, dunno about Kitty.
I can confirm that I just do it over ssh fine all the time -- gnuplot, img2sixel as an "image-cat", etc. (`st` with patches to add sixel support as discussed in various places in these comments.)
I’ve found it useful, when paired with a terminal file manager, to preview graphics in the terminal.
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.
Check x2go.
> I wish there was a high performance way of remoting graphics over SSH. How cool would it be if you could SSH to a remote machine and it just showed you the remote desktop in the terminal itself? No messing around with port forwarding, weird X servers, etc
I think there's at least three different experiences here, and they're all valid, but I don't know what you really want.
A) remote desktop --- connect to a fully formed desktop environment (with SSH to authenticate, I guess?), possibly persisted and/or shared so you can connect back and get into the same place or share with another user?
B) run a program remotely and display it on your local terminal; essentially remote X, but I gather you're looking for more performance and maybe some other nice to haves? Maybe you want to transport audio too... Maybe you don't want the crap experience remote X has become since app developers don't spend any effort on it and you kind of get what you get, which is a lot of jank.
C) images in the terminal, with high performance. PNG should be ok for that, right? Maybe an extension for lossy compression might be nice depending.
Yeah I want all of those. Only the third one really works at the moment but it's also the least useful. The second one I think would be the most transformative because then all the TUI apps people use like htop, ncdu and so on can have decent graphics.
At that point you're really better off using some other remoting protocol instead of trying to tunnel it all over a terminal session. There's nothing left of the original terminal.
There is though - the ssh authentication and connection is already handled, and I'm already in a terminal. When I quit the app or session I'm back in the terminal.
If it worked it would greatly reduce the hassle.
Think about all the TUI apps that exist. They're useful because they're convenient when working in a terminal, not because they look like shit.
If I want to view an image file on a remote machine, and all I have is ssh... I just connect to that machine with filezilla and click on whatever files I want. I can even open files that aren't PNG! Even files that aren't even images at all. Mindblowing.
A terminal with in-band graphics primitives is called an RDP client.
We've had graphics terminals since RIP BBS's and even before that. If they were actually useful enough to be worth the bother, then we'd all have been using them all along and there wouldn't be posts like this.
It's not a case of there's this awesome idea that just for some reason no one knows about. No, it's just not that awesome of an idea. It's not harmful so it doesn't bother me that most xterms support tektronix graphics, it's just a gimmick of no real value. It's a solution to no problem.
Don't believe me? When was the last time you used passthrough printing? Or saw it being used even in some place where they do actually need to print? The terminals all still support it. It's just a thing that you don't need to do in-band in a tty, and today there is no reason to bother doing it that way even though you could. It's not better and does not solve a problem.
With sshfs and 'rclone mount' you forget the shell and everything it's a filesystem.
I don't think viewing files is the most compelling use case for this.
> I just connect to that machine with filezilla
"Just" carries a lot of hassle, and this only applies to viewing files.
What you are looking for is forwarding an X session via SSH, and that has been supported since the dawn of time.
> Probably too many GUI naysayers and "What's wrong with remote X?" for this to ever happen though.
Is there a wayland equivalent?
Closest is wprs
https://github.com/wayland-transpositor/wprs
I have yet to use it though because Wayland still doesn't work properly for me (it doesn't restore the desktop properly after sleep) so I'm still on X11... without compositing... because KWin's compositor causes random freezes.
Yeay, Linux on the Desktop.
Yes, waypipe
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.
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...
There is an in-terminal wayland compositor (or two?) out there, fwiw.
Edit- one example https://github.com/mmulet/term.everything
well iTerm2 now has a #&*%( web browser built in...
Yes! Hoping I can get Neomutt to render HTML email without resorting to launching a browser.
Since URLs are clickable in iTerm, you have the option to view a webpage in the terminal.
By "browser" here, you mean lynx or links or w3m etc, right?
Assuming so, what would be the benefit of rendering within neomutt instead of lynx?
Does "calling a system provided-component" (WKWebView) count as "built-in"?
Clicking a link to launch an external web browser: no
Viewing a webview inside the app itself: yes
`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.
I had some issues with Wezterm fonts - I was able to configure it away: https://github.com/bbkane/dotfiles/tree/master/wezterm#fixed...
> 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.