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!
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.
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).
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.
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”).
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.
Control in its typical position however drives me crazy.
[EDIT]: so ... tried it ... very, very nice BUT:
what of CTRL-V ???
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.
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.
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.
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.
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]
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.
Can you paste in a non-terminal app though (like a web browser) ?
Are there any legitimate reasons to send Ctrl-C except to abort, that this could interfer with?
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.
You, uh, never tried middle clicking?
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 would avoid doing the PTY thing and instead do this (works on WSL if MAME is the windows version):
$ sudo socat TCP-LISTEN:1234,reuseaddr,fork EXEC:"/sbin/agetty -L - 9600 vt102",pty,setsid,ctty,stderr
$ mame -nomouse vt102 -rs232 null_modem -bitb socket.localhost:1234
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.
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).
The really interesting ones are VT340 variants with ReGIS and full SIXEL graphics
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...)
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 ;)
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?
This is a KDE thing; it'll open in whatever terminal you've got configured in Default Applications.
- 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>.
Overall, it literally looks like a better Alacritty alternative. The creator(s) did a great job!
(I know you can fake scrollback search with tmux. It's not the same.)
@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 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!
https://www.gnu.org/software/bash/manual/bash.html#index-rev...
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 made for a more fun first experience with a terminal emulator than I expected to have.
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?)
Update: Windows Terminal doesn't do it either.
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?
- 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).
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)
* 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 see in config file, actions { "id": "User.find", "keys": "ctrl+shift+f" },
so probably I did
My terminal.app color scheme uses P3 colors on 7% gray rather than the usual sRGB colors so that I can use an OKLCH equidistant palette, and I make extensive use of shift-cmd-up to select and copy “the previous command’s output”. I considered switching for 24-bit color but ultimately I prefer not having to learn a new “rudimentary” app that’s deficient versus my nostalgia just like all the others, and it drastically reduces my stress level when working on other people’s devices that I am proficient in working with an OEM environment.
I occasionally use tabs but for the most part I prefer windows, so that I can drag them around and over/underlapped with other work I’m doing in my GUI. Not a big fan of screen and tmux except as their limited value to me in mitigating ssh disconnects when that’s a concern.
Perhaps your definition of power user is limited to uses aligned with your own?
I 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.
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.
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.
Sigh.
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.
https://ucs-detect.readthedocs.io/sw_results/vscodeterminal....
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.
By contrast, the tested version of ghostty v1.2.3 is two weeks old.
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.
It's just not enabled by default.
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 :)
But I'm no power user.
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).
This would allow TUIs to use recent unicode characters which may not be supported (e.g. Symbols for Legacy Computing), or private use characters (e.g. powerline symbols & font-awesome icons), while falling back to a more universally supported character in terminals that do not support them.
I tried `echo "\e[c"` (send device attributes) on mintty 2.8.1 just now and got "4" back ("VT132 with Advanced Video and Graphics").
- 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
setxkbmap -us option ctrl:swapcaps -option compose:rwin
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.
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.
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.
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.
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".
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.
[1] https://yazi-rs.github.io/
[0] https://www.osnews.com/story/26315/blit-a-multitasking-windo...
Off the top of my head.
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.
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.
Kovid documented his rationale at some length here: https://github.com/kovidgoyal/kitty/issues/33
https://gitlab.freedesktop.org/terminal-wg/specifications/-/...
https://gitlab.freedesktop.org/terminal-wg/specifications/-/...
there's lengthy discussion from just about everyone at this point in those threads, about why images in terminals is Hard
I wish there was a high performance way of remoting graphics over SSH. How cool would it be if you could SSH to a remote machine and it just showed you the remote desktop in the terminal itself? No messing around with port forwarding, weird X servers, etc.
I think probably that requires a full fat video codec like H.264 to work well though. Or maybe RDP?
Probably too many GUI naysayers and "What's wrong with remote X?" for this to ever happen though.
I 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.
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.
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 just connect to that machine with filezilla
"Just" carries a lot of hassle, and this only applies to viewing files.
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.
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.
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...
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.
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.)
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.
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.)
This is the actual end game of the worse is better philosophy.
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.
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...
Edit- one example https://github.com/mmulet/term.everything
Since URLs are clickable in iTerm, you have the option to view a webpage in the terminal.
Assuming so, what would be the benefit of rendering within neomutt instead of lynx?
Viewing a webview inside the app itself: yes
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.
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.
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.
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).
Should I switch to something else or just keep on truckin?
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.
Very customizable and extensible using Lua. Extensive documentation, native ssh support and built-in multiplexing.
I prefer it's UI and level of customization.
Ghostty animations run like crap for me on linux (not sure why).
It has a very extensive Lua API.