Are you seeing problems or is this for theoretical correctness?

Unfortunately the terminfo system has pretty huge problems (most terminals claim to be "xterm" so it's usually ineffectual, and the ones that don't might have problems because the terminfo database doesn't have the entry).

That means it's also just a heuristic and often other things might be more helpful. Depends on the case you're seeing, which is why I'm asking.

Are you seeing problems or is this for theoretical correctness?

It is a real problem for a new terminal emulator that I'm helping to test. It's not listed in the known list of terminals, so fish incorrectly assumes it's not capable of setting the title. This terminal does ship its own terminfo entry that contains the ts capability.

Unfortunately the terminfo system has pretty huge problems (most terminals claim to be "xterm" so it's usually ineffectual, and the ones that don't might have problems because the terminfo database doesn't have the entry).

Understood, but in this case I think it's low risk. If the check fails it falls back to the existing heuristics. So this only impacts terminals which ship a terminfo that contains the ts capability.

Another alternative would be to query support from the terminal itself using OSC 60, but I have no idea how widely that is implemented.

It is a real problem for a new terminal emulator that I'm helping to test. It's not listed in the known list of terminals

Does this terminal have a name or is that not public knowledge?

Another alternative would be to query support from the terminal itself using OSC 60, but I have no idea how widely that is implemented.

Querying scares me. I don't like the idea of sending something and getting a response maybe, possibly, but later. How long do we wait?

And I've seen terminals spew querying escapes, so I don't like it.

Understood, but in this case I think it's low risk. If the check fails it falls back to the existing heuristics.

My "fear" is that something may pick a terminfo entry that does list ts, but doesn't actually support it. Maybe it's just a bug in that entry on that OS - the terminfo database is annoyingly sticky, especially on things like macOS (do they list italics for terminal.app yet?).

Still, terminfo may be the least bad option.

(tbh my favorite solution would be for all terminals to simply support this enough to be able to just ignore a title, so we could just set it unconditionally)

Does this terminal have a name or is that not public knowledge?

It is called ghostty. It's currently in a closed beta testing period.

Querying scares me. I don't like the idea of sending something and getting a response maybe, possibly, but later. How long do we wait?

Yea I agree, I mentioned it as a possibility but it's not my preference in this case either.

My "fear" is that something may pick a terminfo entry that does list ts, but doesn't actually support it. Maybe it's just a bug in that entry on that OS - the terminfo database is annoyingly sticky, especially on things like macOS (do they list italics for terminal.app yet?).

Still, terminfo may be the least bad option.

We could reduce this risk further by only checking for ts after some of the other heuristics have failed.

So before falling back to checking the stdin TTY device name, check ts. But this would only happen when $TERM does not match any of the terminals in the known good list or any of the other terminals in the known bad list.

After further consideration I'm just gonna merge this as-is. It's not like the terminal title is some new obscure feature.

It should be table stakes. Any good terminal standard would just enforce that the sequence is understood (sadly we do not live in a world with a good terminal standard).

I'm still extremely sad at the state of current terminal cross-compatibility and that we're still relying on the broken and near useless terminfo.