starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Feature Request - Restore closed tab #1283

New Issue
Closed
opened 2026-01-30 22:20:59 +00:00 by claunia · 8 comments
claunia commented 2026-01-30 22:20:59 +00:00
Owner
Copy Link

Originally created by @AClerbois on GitHub (May 23, 2019).

Hello,

I'd suggest a restore tag feature like in internet browser. For example, you close a tab and press [CTRL] + [SHIFT] + [T] and that will restore the latest tab closed.

May be without the context in the first step but with the latest path.

P.S. : Thank you for your awesome project,, I'm very excited to use the final preview version with the new font.

Originally created by @AClerbois on GitHub (May 23, 2019). Hello, I'd suggest a restore tag feature like in internet browser. For example, you close a tab and press [CTRL] + [SHIFT] + [T] and that will restore the latest tab closed. May be without the context in the first step but with the latest path. P.S. : Thank you for your awesome project,, I'm very excited to use the final preview version with the new font.
claunia commented 2026-01-30 22:21:00 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 23, 2019):

So tracking the most recently closed tab wouldn't be that hard. We could keep a stack of profiles as we close them, and just pop from that stack when we want to reopen one. That's not too hard.

What is hard is restoring state. Even restoring the path of the executable that was running might be incredibly tricky - can we get the cwd of an arbitrary executable? What if the executable was ssh, which in some directory in a remote machine? We certainly wouldn't be able to restore that connection. What if the path no longer exists? If we CreateProcess a process in a directory that doesn't exist, what happens? Do we just default to the profile's default? What if your cmd.exe profile was running powershell, and powershell had changed to some other directory? We can't restore the process tree, and because this is Windows, there isn't the concept of a "foreground" process attached to a conpty, so we'd have to default to using the state from the executable at the root of the process tree.

Just some thoughts off the top of my head. I'm sure @malxau actually has a lot more on this if I remember my email inbox correctly.

I want to make sure that this issue specifically tracks "restoring the last closed tab's profile" and not "restore it's state" because the former is easy and the latter is hard. We should probably have more discussion of the latter in a new issue, #961.

Actually now that I've typed #961 up, I had an idea. This might have to be something that the user opts in to, but we could theoretically just keep the TermControls from the N most recently closed tabs panes alive in the stack, and when the user reopens the tab, we just put the control back into the tab pane. I'm suggesting this is opt-in, since we'd be keeping some number of controls alive, including all the processes attached to them. This would definitely seem like a memory leak, unless the user has opted in to this behavior, and the user would almost certainly

  1. need to know this was happening
  2. have a way to manually shut these saved instances down
@zadjii-msft commented on GitHub (May 23, 2019): So tracking the most recently closed tab wouldn't be that hard. We could keep a stack of profiles as we close them, and just pop from that stack when we want to reopen one. That's not _too_ hard. What _is_ hard is restoring state. Even restoring the path of the executable that was running might be incredibly tricky - can we get the cwd of an arbitrary executable? What if the executable was ssh, which in some directory in a remote machine? We certainly wouldn't be able to restore that connection. What if the path no longer exists? If we CreateProcess a process in a directory that doesn't exist, what happens? Do we just default to the profile's default? What if your cmd.exe profile was running powershell, and powershell had changed to some other directory? We can't restore the process tree, and because this is Windows, there isn't the concept of a "foreground" process attached to a conpty, so we'd have to default to using the state from the executable at the root of the process tree. Just some thoughts off the top of my head. I'm sure @malxau actually has a lot more on this if I remember my email inbox correctly. I want to make sure that this issue specifically tracks "restoring the last closed tab's profile" and not "restore it's state" because the former is easy and the latter is _hard_. We should probably have more discussion of the latter in a new issue, #961. <hr> Actually now that I've typed #961 up, I had an idea. This might have to be something that the user opts in to, but we could _theoretically_ just keep the TermControls from the N most recently closed ~~tabs~~ panes alive in the stack, and when the user reopens the tab, we just put the control back into the ~~tab~~ pane. I'm suggesting this is opt-in, since we'd be keeping some number of controls alive, including all the processes attached to them. This would definitely _seem_ like a memory leak, unless the user has opted in to this behavior, and the user would almost certainly 1. need to know this was happening 2. have a way to manually shut these saved instances down
claunia commented 2026-01-30 22:21:00 +00:00
Author
Owner
Copy Link

@desmondkung commented on GitHub (May 24, 2019):

I don't think restoring state is a good idea, especially from a security perspective. If I'm a bad actor and try to run terminal that restores state, it's like opening a box of surprises, which might make my work easier.

@desmondkung commented on GitHub (May 24, 2019): I don't think restoring state is a good idea, especially from a security perspective. If I'm a bad actor and try to run terminal that restores state, it's like opening a box of surprises, which might make my work easier.
claunia commented 2026-01-30 22:21:01 +00:00
Author
Owner
Copy Link

@Rosefield commented on GitHub (Oct 8, 2021):

In light of the changes for #766 the version of this which is just re-opening the profile should be relatively easy

  • When closing a pane call Pane::GetTerminalArgsForPane 479ef264b2/src/cascadia/TerminalApp/Pane.cpp (L122)
    on the closed pane and add that to a stack of recently closed panes
  • To restore the recently closed pane either make a new tab using those new terminal args, or make an automatic split on the currently focused pane using those new terminal args.
  • To save/restore multiple panes you can call Pane::BuildStartupActions to get the list of actions to restore that tree of panes, and depending on if you are making a new tab or just attaching to the current pane you prepend a new tab / split pane command like the logic in TerminalTab::BuildStartupActions. 479ef264b2/src/cascadia/TerminalApp/TerminalTab.cpp (L454-L467)
    The history stack could just be a std::vector<std::vector<ActionAndArgs>> and restoring would then just be popping and executing a list of actions.
@Rosefield commented on GitHub (Oct 8, 2021): In light of the changes for #766 the version of this which is just re-opening the profile should be relatively easy - When closing a pane call `Pane::GetTerminalArgsForPane` https://github.com/microsoft/terminal/blob/479ef264b2d9e284db1fc8457f3897d1b19ac32e/src/cascadia/TerminalApp/Pane.cpp#L122 on the closed pane and add that to a stack of recently closed panes - To restore the recently closed pane either make a new tab using those new terminal args, or make an automatic split on the currently focused pane using those new terminal args. - To save/restore multiple panes you can call `Pane::BuildStartupActions` to get the list of actions to restore that tree of panes, and depending on if you are making a new tab or just attaching to the current pane you prepend a new tab / split pane command like the logic in `TerminalTab::BuildStartupActions`. https://github.com/microsoft/terminal/blob/479ef264b2d9e284db1fc8457f3897d1b19ac32e/src/cascadia/TerminalApp/TerminalTab.cpp#L454-L467 The history stack could just be a `std::vector<std::vector<ActionAndArgs>>` and restoring would then just be popping and executing a list of actions.
claunia commented 2026-01-30 22:21:01 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 8, 2021):

The implementation I had considered was simply hanging on to the last N TermControls when they get closed, to allow someone to fully restore that many panes. That way, if someone accidentally closed a long running command, then the whole command would come back with it.

Now, that of course had the downside that closing a pane wouldn't necessarily terminate the process in it. So your way is probably good even in addition to the active command restore

@zadjii-msft commented on GitHub (Oct 8, 2021): The implementation I had considered was simply hanging on to the last _N_ TermControls when they get closed, to allow someone to fully restore that many panes. That way, if someone accidentally closed a long running command, then the whole command would come back with it. Now, that of course had the downside that closing a pane wouldn't necessarily terminate the process in it. So your way is probably good even in addition to the active command restore
claunia commented 2026-01-30 22:21:01 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 11, 2022):

When we market this feature, we should be very clear on what it does. If I recall correctly:

This does not restore the application running in the closed tab. The restore action restores a facsimilie of the closed session, but the application that was running in it doesn't keep running.

@DHowett commented on GitHub (Jan 11, 2022): When we market this feature, we should be very clear on what it does. If I recall correctly: _This does not restore the application running in the closed tab. The restore action restores a facsimilie of the closed session, but the application that was running in it doesn't keep running._
claunia commented 2026-01-30 22:21:02 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Feb 3, 2022):

:tada:This issue was addressed in #11471, which has now been successfully released as Windows Terminal Preview v1.13.10336.0.🎉

Handy links:

@ghost commented on GitHub (Feb 3, 2022): :tada:This issue was addressed in #11471, which has now been successfully released as `Windows Terminal Preview v1.13.10336.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.13.10336.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
claunia commented 2026-01-30 22:21:02 +00:00
Author
Owner
Copy Link

@tJKkeZQoZlcssuXjVjNerQ commented on GitHub (Mar 14, 2022):

🎉Este problema se solucionó en #11471, que ahora se ha publicado correctamente como .Windows Terminal Preview v1.13.10336.0🎉

Enlaces prácticos:

Aun existe un loop al iniciar el terminal. ocurre despues de guardar los cambios del terminal y poner el perfil que inicie como administrador y al abrirlo de nuevo. queda abriendo y cerrando el proceso pero nunca lo muestra.

@tJKkeZQoZlcssuXjVjNerQ commented on GitHub (Mar 14, 2022): > 🎉Este problema se solucionó en #11471, que ahora se ha publicado correctamente como .`Windows Terminal Preview v1.13.10336.0`🎉 > > Enlaces prácticos: > > * [Notas](https://github.com/microsoft/terminal/releases/tag/v1.13.10336.0) > * [Descargar tienda](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge) Aun existe un loop al iniciar el terminal. ocurre despues de guardar los cambios del terminal y poner el perfil que inicie como administrador y al abrirlo de nuevo. queda abriendo y cerrando el proceso pero nunca lo muestra.
claunia commented 2026-01-30 22:21:02 +00:00
Author
Owner
Copy Link

@swinder0161 commented on GitHub (Apr 13, 2022):

The problem with this is the tab position is not restored, if tab closed is first one, the restored tab is the last one.
the position should also be restored

@swinder0161 commented on GitHub (Apr 13, 2022): The problem with this is the tab position is not restored, if tab closed is first one, the restored tab is the last one. the position should also be restored
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings Area-UserInterface Issue-Feature Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#1283
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?