Keybinding to reopen last closed tab

[pnodet]

Nice to have enhancement: being able to reopen the last closed tab (in the same directory).

It's something I use on web browser and sometimes I happen to close a tab quickly, I'd love to be able to reopen it as quickly.

[mitchellh]

I've also done this a few times and I've never found a terminal that does this. I agree it'd be super nice. Tagged.

[stgarf]

I think I recall iTerm2 sorta does this if you press ctrl+z (Undo) within a configurable amount of time.

[pnodet]

Imho cmd+shift+T feels more "natural" or maybe I'm more use to it.
However, the idea of "up to x seconds" goes to show that you mostly use it for something you just killed inadvertently. It differs from browsers where you history is kept, in a terminal you just need the last one closed I guess.

[mitchellh]

All things considered, it's pretty cheap in terms of memory to maintain a stack of prior closed surfaces, so I don't mind keeping it for awhile. I didn't mark this contrib friendly because it's going to require some work across apprt and core. I think we should do the following:

• core: API for maintaining the stack of recently closed surfaces. We probably need some namespacing here so that the apprt can create multiple stacks per window or something like that.
• apprt: determines when that API is called to push/pop, because only the apprt knows the difference between a tab, window, split, etc.

I guess behavior questions:

• Should this be per-window? i.e. if I close a tab in window A, then another in window B, and I go back to window A and press cmd+shift+T, which tab does it restore?
• Should this work for splits? If I close a split and press cmd+shift+T does that restore the split I just closed? (On this one, I vote no initially but we may want to consider it from a core design perspective)

[nskazki]

Hello, Mitchell! Appreciate the support for "quick terminal" and jump_to_prompt! The only other feature I need to migrate from Iterm2 is this. Is this something you plan on doing in the coming year, or is the feature a low priority?

[xwillq]

+1 for this feature.

To add some info, when you undo, iTerm doesn't simply create new session.

• If a pane was closed, it will be restored in the same tab at the same position and it will keep it's configuration, e.g. font size, background color, size, etc.
• If a tab was closed, it will be restored in the same window at the same position in the tab bar. All panes inside that tab will be restored, keeping their configurations.
• If a window was closed, it will be restored at the same position and with the same dimensions. All tabs inside that window will be restored, keeping their configurations.
• When you close a session, iTerm doesn't kill process running inside of it. So, when you restore a session, you will keep all of the state. Your editor will be running, your ssh connection will be intact. This is the main reason why iTerm has a time limit for session restoration - it has to kill these processes at some point.
• When you restore a session, it will keep it's scrollback buffer. This is a second reason for time limit.

As to how this feature should work in Ghostty, I don't think that simply opening a new surface in the same working directory as previously closed one is very useful. Sure, it can be convenient if you don't want to cd again, but you can solve this problem using shell (I believe fish allows you to type cd and hit up to bring last cd from history, also there is a plugin for zsh that does the same).
For me, the most important thing with this feature is that you can restore scrollback buffer. What if I set up some service that randomly generates a password for me and prints it to the terminal and I accidentally closed the tab? Or run some destructive command that outputs some info? In this cases, I don't want to or can't redo what I did to get the same info, so restoring scrollback buffer is very important.
Process restoration seems less useful to me, because confirmation for closing surfaces mostly alleviates the problem of accidentally closing a surface with some important process running.

[mitchellh]

Due to the amount of apprt-specific metadata required (tab vs split vs window, positions, etc.), I'm going to adjust my previous implementation recommendations and say this should be implemented totally custom at the aport-level.

For macOS, it may be desirable to integrate this directly with UndoManager.