[dwedge]

I like the look of this terminal, but it doesn't work correctly with SSH (top, ncdu for example) unless you hack the $TERM variable. It feels a bit vibecoded even though it isn't.

To give a little productive criticism, one thing I really miss is when having tiled terminals, I want to be able to full screen one of them temporarily. Double click in iterm allows this, so does mod+f in i3wm. It really is the only thing stopping me from switching to this (and I admit it might be buried somewhere in the settings)

[mitchellh]

> To give a little productive criticism, one thing I really miss is when having tiled terminals, I want to be able to full screen one of them temporarily.

I think you're looking for the `toggle_split_zoom` binding which has existed since Ghostty 1.0 and is default bound to `cmd+shift+enter` on macOS which is the same binding as iTerm. It's also visible in the menu and command palette.

We recently added a kind of split title bar, making it double click to zoom is a good idea. I'll add an issue for that to the roadmap.

[dwedge]

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

[znpy]

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.

[dagi3d]

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

[1f60c]

Using its own TERM is a deliberate design decision. I don't remember how to fix the terminal database, but it's pretty easy (your favorite search engine or LLM should be able to help you there).

[ubercow13]

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

[frereubu]

https://ghostty.org/docs/help/terminfo#ssh

[hijinks]

i had to do this for ssh

host * SetEnv TERM=xterm-256color

[FireBeyond]

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'.

[NoboruWataya]

I don't know enough about these things to know why, but I have pretty much always had to hack $TERM to get things working smoothly with any remotely featureful terminal emulator. I have occasionally needed similar hacks for Kitty and urxvt, for example (though top and ncdu seem to work fine).

The way terminal applications handle different terminal emulators on Linux just seems to be a bit broken. I don't think it's a particular indictment of Ghostty or any one emulator.

[dwedge]

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

[heftig]

I wish TERM would contain a list of terminal types in decreasing order of specificity, like 'ghostty:xterm-256color', so a system that doesn't know what ghostty is would fall back to xterm-256color, but that ship has sailed long ago.

[paxys]

I have tried every possible setting but SSH ends up breaking more often than not. As opposed to iTerm which just works.

[Jare]

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.

[DiabloD3]

It sounds like you simply forgot to update your terminfo on your remote system.

You must do this if your chosen terminal requires settings that are not compatible with "xterm-256color".

Alacritty, kitty, and wezterm also require this, as they implement features that xterm doesn't (and most likely never will), if your terminfo DB is too old to already include them.

Using Alacritty as an example, you'd take a file that looks like this, https://github.com/alacritty/alacritty/blob/master/extra/ala... , and run `tic -x -o "~/.terminfo" "that.info"` on it.

Its been this way for like 30 years, and it'll never change.

[Brian_K_White]

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.

[dwedge]

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.