I could have sworn I checked every menu option but it is there, thank you

Can I take advantage of you being here and express some desiderata?

1. The quick terminal feature is ghostty's killer feature for me, I switched to ghostty because of it. Could we make it first-class feature? Like, i'd love to have tabs over there too (like in guake/yakuake).

2. I have a white on black theme (white text on black background) but when i split vertically/horizontally, the borders between one shell and the next are not really visible and I have an hard time resizing them... Can you do something about it? Setting the colors of borders would be an okay fix for me.

also, from not that long time ago, you can change the focus of panes and you can tell it to respect the zoom state if you want, which is super convenient

Or the manual, which describes the features for automatically handling it.

i had to do this for ssh

host * SetEnv TERM=xterm-256color

I definitely have had to poke at things a bit, even where they "should" work. I use salt in my homelab and eventually got the xterm-ghostty.terminfo file and I put it in my baseline salt config, then you run 'tic -x xterm-ghostty.terminfo'.

I just checked Kitty and top fails on Debian 12, so I think I was unfair in just calling out Ghostty for this

Same here. I have a Ghostty often open but end up using iTerm2 for pretty much everything. It's not just having to hack the TERM (which I ended up doing), it's that sometimes something about the TERM internally breaks anyway and I'm back to seeing ESC codes when I press an arrow. Quit & restart fixes it but it's just enough friction to keep me away.

If you have to configure the host to support the client rather than the client supporting unknown existing hosts, then what you have is a terminal, not a terminal emulator.

In 1970 all terminals were their own thing, tied to a single host somewhere in the same building by a dedicated serial cable. The terminal didn't move or connect to random other hosts, and the host had to be specially configured to work with any terminal connected to it.

Since then, a few terminal definitions have become standardized across all hosts for decades, and terminals are emulators that emulate one of those 40 year established standard definitions, because today terminals connect to countless unknown new random and varied hosts that the terminal user didn't install and configure before connecting, and may not even have the admin rights to do so after the fact either, and even if they do, it's wildly and inexcusably awful to require that.

It's entirely backwards for a terminal today to default to asserting it's own new $TERM, and to characterize the problems caused by this as "the user forgot to do this totally unreasonable thing" that no other terminal or terminal emulator has required for 40 years.

It's 100% a bug. The fact that it's intentional just means it's a design goal bug.

It might be a bug in remote handling and I might have unfairly called out GhostTTY for this, but "forgetting to update terminfo on my remote system" just doesn't hold with the way I work.

I work managing different systems for different clients and often login to systems for the first time. The servers aren't mine, and configuring something like Ansible to configure my home just seems like a waste of time for little benefit. It means that generally I end up using systems that are likely to be already instead - Bash not zsh, Perl, basic vim without any bindings. It might sound special but I'm sure I'm far from the only person working this way.

So given this, I'd always prefer a terminal that doesn't require me to change remote servers. In this particular case I can modify $TERM in my local .zshrc and it works fine so it's a moot point, but if I had to modify the remote system it would be a no go.

    SetEnv TERM=xterm-256color