Title is not restored when exiting alternate screen mode

[lilyball]

Title strings set while in alternate screen mode should be discarded when exiting alternate screen mode, reverting back to the title that was in use before. Proxy icon too. Right now this isn't happening. This is why Vim leaves the title as "Thanks for flying Vim" in Ghostty but not in Terminal.app.

Reproduction steps:

tput smcup
printf '\e]2;foo\a'
tput rmcup

Running this in Terminal.app leaves the title as it was before (insert sleeps or run it interactively if you want to see the title change). Running this in Ghostty leaves the title at "foo".

Interestingly iTerm also does this wrong and doesn't restore the title with that script, though iTerm is restoring when Vim exits so it must be using some other logic there. I checked the "raw" mode escapes but that didn't seem to do anything, so I don't know what it's doing. But Terminal.app's behavior makes the most sense, of restoring the title/proxy when exiting alternate screen mode, and Ghostty should probably copy that.

[mitchellh]

I converted this to a discussion so we can do some research first. Terminal.app is not a good source of behavior for VT sequences since it is generally known to very very poorly emulate (see notcurses source for a lot more details).

I want to mainly verify with xterm here. I’m not sure if the title is meant to be screen specific state, I was under the impression it was terminal meaning it should not be restored.

I’ll check in on this in time but if anyone else can that’d be great. Having accompanying shell scripts makes this much easier.

[lilyball]

xterm supports querying the title (though I believe this is usually disabled as a security issue). There's also a push/pop title stack that again I believe xterm is the only terminal that actually supports it (Vim says this is CSI 22 ; 2 t and CSI 23 ; 2 t). When running under X Vim actually reads the X window title if it can. On exit, Vim will leave raw mode, then set the title to "Thanks for flying Vim" (or the old title if it knows it, which it does under X11), then it will send the CSI 23 ; 2 t code to try and pop the title, then it exits termcap mode, and a few other fiddly bits.

So when running xterm, Vim will both restore the title that it got via X11, and it will pop the title stack with CSI 23 ; 2 t, and the alternate screen doesn't matter at all for this. I don't know about other programs though, e.g. I don't know the exit sequence for tmux.

Ultimately I do think Terminal.app has the right idea here. Any title set during alternate screen mode is presumably specific to what is being done in the alternate screen, and when alternate screen mode ends, the title is unlikely to be relevant anymore.

Interestingly, whatever iTerm is doing to restore the title after Vim ends doesn't work for tmux and zellij. Terminal.app restores its title when those two end but iTerm doesn't.

[lilyball]

It occurred to me that I actually have a Linux machine with a GUI available to me so I just tested. Xterm restores the window title when exiting alternate screen mode. To be specific, I ran

printf '\e]2;orig\a'; tput smcup; printf '\e]2;foo\a'; sleep 1; tput rmcup; sleep 1

and what happened was it had the title "foo" in alternate screen mode, and when it switched back it had the title "orig".

[lilyball]

Actually there's a subtlety here. Xterm's smcup and rmcup strings include the title stack manipulation. More specifically, smcup=\E[?1049h\E[22;0;0t and rmcup=\E[?1049l\E[23;0;0t. So it's technically that \E[22;0;0t and \E[23;0;0t bit that deals with the title (and window icon). But that's part of smcup/rmcup and so any terminal that does not reimplement those CSI 22 ; … t / CSI 23 ; … t escapes should be doing it as part of the CSI ? 1049 l escape.

[mitchellh]

Ghostty doesn't yet support title push/pop. That can be another feature request but for now let's focus on what the alt screen behavior should be. Here is my test script:

function csi() {
  echo -ne "\033[$1m"
}

echo -ne "\033]2;Outside\a"
read
csi "?1049h"
echo -ne "\033]2;Inside\a"
read
csi "?1049l"
read

And the results, "yes" means restore:

• Terminal.app - yes
• iTerm2 - no
• Kitty - no
• Alacritty - no
• WezTerm - no
• Warp - no
• xterm - no
• Gnome Console - no
• Foot - no

Given this, it's quite clear to me without having to spelunking through the xterm source code that mode 1049 does not restore the window title. Terminal.app does it but we do not follow Terminal.app as truth when it comes to VT sequences (GUI and stuff is different).

[mitchellh]

Created #2668 to support push/pop. I think that concludes this idea's investigation. ❤️ (Feel free to keep commenting if there is something I missed)

[lilyball]

Given this, it's quite clear to me without having to spelunking through the xterm source code that mode 1049 does not restore the window title.

Yes that's true, it's not mode 1049 it's rmcup that does. Terminal.app implements this by attaching it to the mode 1049 sequence because it doesn't implement the stack, but that only matters to people emitting sequences directly without consulting the terminfo database. Also worth pointing out that macOS's xterm-256color terminfo entry only defines rmcup as the mode 1049 sequence. Ghostty is providing its own terminfo entry so it can do this using the push/pop sequence, but if iTerm achieves this with push/pop then that would explain why the smcup/rmcup test I did didn't work there, and also explains why it didn't restore title after tmux and zellij exited.

It's worth noting that by supporting this using push/pop, SSH'ing into another macOS machine and falling back to setting TERM=xterm-256color (instead of copying the Ghostty terminfo entry over) will therefore cause the window title to break. I'm not saying this to suggest we should try to do something about it, it's just something to be aware of.