Hacker News new | past | comments | ask | show | jobs | submit
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)

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

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.

> The quick terminal feature is ghostty's killer feature for me

Just FYI, it's in Kitty nowadays too: https://sw.kovidgoyal.net/kitty/kittens/quick-access-termina.... The quick-access terminal is a regular terminal, so you get normal tabs, splits, etc. there.

2. I think split-divider-color does what you want.
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
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).
Or the manual, which describes the features for automatically handling it.
{"deleted":true,"id":47207427,"parent":47207327,"time":1772377989,"type":"comment"}
If I install a terminal and SSH doesn't work from it out of the box, I would describe that as a bug and wonder if I need to read the full manual to not fall foul of other gotchas
It is a bug.. But not with Ghostty...
What do you think the bug is, exactly?
Servers throwing "missing or unsuitable terminal" even when the connecting terminal is available and very suitable. And this is just because they hardcode xterm as the "standard".
{"deleted":true,"id":47208979,"parent":47208570,"time":1772387663,"type":"comment"}
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 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.

I just checked Kitty and top fails on Debian 12, so I think I was unfair in just calling out Ghostty for this
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.
I have tried every possible setting but SSH ends up breaking more often than not. As opposed to iTerm which just works.
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.
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.

loading story #47209326
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.

loading story #47208143