Restore previously closed session&#39;s state (Buffer contents) #1279

@jamieghassibi commented on GitHub (Apr 4, 2020):

@malxau While all the complications make saving state difficult, I don't feel simply saving the tabs, tab names, panes, and their respective directories should be relatively simple.

Having different session setups could also be possible as an argument to wt, for example I could type win+r wt session foo to open the foo session. Saving could be accomplished via wt session -s foo.

Thinking about the above suggestion, it may be easier to add a section to the options JSON that let's users describe a session layout.

@jamieghassibi commented on GitHub (Apr 4, 2020): @malxau While all the complications make saving state difficult, I don't feel simply saving the tabs, tab names, panes, and their respective directories should be relatively simple. Having different session setups could also be possible as an argument to wt, for example I could type win+r `wt session foo` to open the foo session. Saving could be accomplished via `wt session -s foo`. Thinking about the above suggestion, it may be easier to add a section to the options JSON that let's users describe a session layout.

claunia commented

@malxau commented on GitHub (Apr 4, 2020):

@JamieGhassibi How would the terminal obtain the directory that is active within the shell processes?

I can see how this would work if the session is defined in config, but to capture the current state into the config still sounds like it's depending on capturing state from the terminal and from all of the command line processes executing within it.

@malxau commented on GitHub (Apr 4, 2020): @JamieGhassibi How would the terminal obtain the directory that is active within the shell processes? I can see how this would work if the session is defined in config, but to capture the current state into the config still sounds like it's depending on capturing state from the terminal and from all of the command line processes executing within it.

claunia commented

@Chris-Dickerson commented on GitHub (May 7, 2020):

I would like to see allowing a definition of tabs to be opened on startup (much like other Windows terminal applications).

As far as restoring state, I accept what happens in the terminal to be volatile. If I want the output, I capture it with the commands executed.

@Chris-Dickerson commented on GitHub (May 7, 2020): I would like to see allowing a definition of tabs to be opened on startup (_much like other Windows terminal applications_). As far as restoring state, I accept what happens in the terminal to be volatile. If I want the output, I capture it with the commands executed.

claunia commented

@nmoinvaz commented on GitHub (May 21, 2020):

It would be great if the Terminal could remember:

List of tabs previously open and their current working directory
List of commands previously ran in each tab (maybe last 10-20)

The actual contents of the buffer are not as important. When I restart my computer or accidentally close the Terminal app, I just want to get back to where I was as quickly as possible.

@nmoinvaz commented on GitHub (May 21, 2020): It would be great if the Terminal could remember: * List of tabs previously open and their current working directory * List of commands previously ran in each tab (maybe last 10-20) The actual contents of the buffer are not as important. When I restart my computer or accidentally close the Terminal app, I just want to get back to where I was as quickly as possible.

claunia commented

@zadjii-msft commented on GitHub (May 22, 2020):

@nmoinvaz So those two might be generically impossible for the Terminal to solve.

This thread:https://github.com/microsoft/terminal/issues/3158#issuecomment-628628120 (and the threads linked to it) has far, far too many details on why it's hard for the Terminal to get the working directory of the current process.
As far as the list of commands run, that's the shell's responsibility, not the Terminal's. The Terminal doesn't know what is and isn't a command the user entered, it only knows about a stream of input it delivered to the client application. Notably, powershell/pwsh and bash already save the command history on exit. cmd is the one notorious exception, and it's not about to be updated to add that support, since that constantly burns us. See https://github.com/microsoft/terminal/issues/217#issuecomment-404240443.

@zadjii-msft commented on GitHub (May 22, 2020): @nmoinvaz So those two might be generically impossible for the Terminal to solve. * This thread:https://github.com/microsoft/terminal/issues/3158#issuecomment-628628120 (and the threads linked to it) has far, far too many details on why it's hard for the Terminal to get the working directory of the current process. * As far as the list of commands run, that's the _shell's_ responsibility, not the Terminal's. The Terminal doesn't know what is and isn't a command the user entered, it only knows about a stream of input it delivered to the client application. Notably, `powershell`/`pwsh` and `bash` _already_ save the command history on exit. `cmd` is the one notorious exception, and it's _not_ about to be updated to add that support, since that constantly burns us. See https://github.com/microsoft/terminal/issues/217#issuecomment-404240443.

claunia commented

@lukaseder commented on GitHub (Jul 1, 2020):

To me, this is just like how browsers allow for reopening tabs. In fact, a terminal kinda is a browser. And while restoring the session might not be easy, restoring the path (and things like the tab title: https://docs.microsoft.com/en-us/windows/terminal/tutorials/tab-title) definitely is (things are never as easy as we users think) seems to be. For my use-cases, that would already be enough

@lukaseder commented on GitHub (Jul 1, 2020): To me, this is just like how browsers allow for reopening tabs. In fact, a terminal kinda *is* a browser. And while restoring the session might not be easy, restoring the path (and things like the tab title: https://docs.microsoft.com/en-us/windows/terminal/tutorials/tab-title) definitely ~is~ (things are never as easy as we users think) seems to be. For my use-cases, that would already be enough

claunia commented

@danyalasif commented on GitHub (Aug 1, 2020):

Came here looking for a save last open tabs feature. I have been using Cmder which has a option to open all last closed tabs just like in a browser, it's a really handy feature let's you get to work where you left. I don't think it restores the history of each shell but just restoring tabs and the directory I was on is massive, just like a browser doesn't save the tab state and open the website like it was when last time you loaded (it refreshes it and opens it anew)

@danyalasif commented on GitHub (Aug 1, 2020): Came here looking for a save last open tabs feature. I have been using Cmder which has a option to open all last closed tabs just like in a browser, it's a really handy feature let's you get to work where you left. I don't think it restores the history of each shell but just restoring tabs and the directory I was on is massive, just like a browser doesn't save the tab state and open the website like it was when last time you loaded (it refreshes it and opens it anew)

claunia commented

@diallobakary4 commented on GitHub (Sep 6, 2020):

Me I mostly worry the tab colors 🙈😊

@diallobakary4 commented on GitHub (Sep 6, 2020): Me I mostly worry the tab colors 🙈😊

claunia commented

@portexe commented on GitHub (Sep 9, 2020):

I created #7574 because I really think that the ability to save the current session is extremely important. There are many scenarios when I as a developer could have really benefited from it. Let's say you have several servers that need to be running in order for your app to work, and you're running them all from your command line through different tabs. It's a huge pain to open these tabs and then cd to each location every time you re-boot your computer or run updates.

What would be fantastic is the ability to save the state of the terminal (ie. the tabs and each of their locations) in a config. That way when you open your terminal, you can simply run a command like: terminal-open savedConfigName and your session will be restored.

@portexe commented on GitHub (Sep 9, 2020): I created #7574 because I really think that the ability to save the current session is extremely important. There are many scenarios when I as a developer could have really benefited from it. Let's say you have several servers that need to be running in order for your app to work, and you're running them all from your command line through different tabs. It's a huge pain to open these tabs and then `cd` to each location every time you re-boot your computer or run updates. What would be fantastic is the ability to save the state of the terminal (ie. the tabs and each of their locations) in a config. That way when you open your terminal, you can simply run a command like: `terminal-open savedConfigName` and your session will be restored.

claunia commented

@portexe commented on GitHub (Sep 9, 2020):

@nmoinvaz So those two might be generically impossible for the Terminal to solve.

This thread:#3158 (comment) (and the threads linked to it) has far, far too many details on why it's hard for the Terminal to get the working directory of the current process.

As far as the list of commands run, that's the shell's responsibility, not the Terminal's. The Terminal doesn't know what is and isn't a command the user entered, it only knows about a stream of input it delivered to the client application. Notably, powershell/pwsh and bash already save the command history on exit. cmd is the one notorious exception, and it's not about to be updated to add that support, since that constantly burns us. See #217 (comment).

Regarding your first point, I believe simply being able to add the location to a config file manually would suffice. There are already a lot of settings that require manual editing of JSON, so this could very well be similar in that way. Perhaps an array of file system locations, and for each item in the array, a tab would be opened to that location.

@portexe commented on GitHub (Sep 9, 2020): > @nmoinvaz So those two might be generically impossible for the Terminal to solve. > > * This thread:[#3158 (comment)](https://github.com/microsoft/terminal/issues/3158#issuecomment-628628120) (and the threads linked to it) has far, far too many details on why it's hard for the Terminal to get the working directory of the current process. > * As far as the list of commands run, that's the _shell's_ responsibility, not the Terminal's. The Terminal doesn't know what is and isn't a command the user entered, it only knows about a stream of input it delivered to the client application. Notably, `powershell`/`pwsh` and `bash` _already_ save the command history on exit. `cmd` is the one notorious exception, and it's _not_ about to be updated to add that support, since that constantly burns us. See [#217 (comment)](https://github.com/microsoft/terminal/issues/217#issuecomment-404240443). Regarding your first point, I believe simply being able to add the location to a config file manually would suffice. There are already a lot of settings that require manual editing of JSON, so this could very well be similar in that way. Perhaps an array of file system locations, and for each item in the array, a tab would be opened to that location.

claunia commented

@aleksey-hoffman commented on GitHub (Oct 25, 2020):

@zadjii-msft, @DHowett guys, why does it take years to implement such simple, highly requested, important features? Don't you want this feature yourself?

Just like @nmoinvaz, @lukaseder, @danyalasif said above, no one asks for a complex system that messes with security, all we need is the ability to restore 2 basic properties for each tab onAppLoad event: tab: { cwd: String, commands: Array<string> }.

It literally takes only 15 minutes to figure out the logic + a few hours to implement it:

Add 1 property to settings: settings: { startupAction: ('restore-last-state'|null) }
Add 1 property to globalStore (where you store shared data): globalStore: { state: { tabs: Array<object> } }
Add each tab 2 properties: globalStore: { state: { tabs: [{ tab: { cwd: String, commands: Array<string> } }] } }
When the state of a tab changes, write the state to storage
On app load, restore state from storage: get storageData.state and set it to globalStore.state

`settings.json`

settings: {
  startupAction: 'restore-last-state',
}

`globalStore`

globalStore: {
  state: {
    tabs: []
  }
}

`storageData.json`

{
 "state": {
    "tabs": []
  }
}

`main`

async function onAppLoad () {
  await initRestoreLastState()
  ...
}

async function initRestoreLastState () {
  if (settings.startupAction == 'restore-last-state') {
    globalStore.state = await getStorageProperty('state')
  }
}

async function getStorageProperty (key) {
  return JSON.parse(getStorageData())[key]
}

function onExecuteCommand () {
  saveTabCommand()
  saveTabCwd()
  writeStateToStorage()
  ...
}

function saveTabCommand () {
  get(stateCurrentTab).commands.push(event.command)
}

function saveTabCwd () {
  get(stateCurrentTab).cwd = getCwdPath()
}

function onNewTab () {
  addTab(event)
  writeStateToStorage()
  ...
}

function addTab () {
  let tab = {
    cwd: '',
    commands: []
  }
  tab.cwd = getCwdPath()
  globalStore.state.tabs.push(tab)
}

function writeStateToStorage () {
  if (settings.startupAction == 'restore-last-state') {
    // Avoid data corruption by writing data synchronously 
    // (file might get corrupted when multiple async processes writing at the same time)
    writeStorageSync('state', globalStore.state)
  }
}
...

@aleksey-hoffman commented on GitHub (Oct 25, 2020): @zadjii-msft, @DHowett guys, why does it take years to implement such simple, highly requested, important features? Don't you want this feature yourself? Just like @nmoinvaz, @lukaseder, @danyalasif said above, no one asks for a complex system that messes with security, all we need is the ability to restore 2 basic properties for each tab onAppLoad event: `tab: { cwd: String, commands: Array<string> }`. It literally takes only 15 minutes to figure out the logic + a few hours to implement it: - Add 1 property to settings: `settings: { startupAction: ('restore-last-state'|null) }` - Add 1 property to globalStore (where you store shared data): `globalStore: { state: { tabs: Array<object> } }` - Add each tab 2 properties: `globalStore: { state: { tabs: [{ tab: { cwd: String, commands: Array<string> } }] } }` - When the state of a tab changes, write the state to storage - On app load, restore state from storage: get `storageData.state` and set it to `globalStore.state` ### `settings.json` ```js settings: { startupAction: 'restore-last-state', } ``` ### `globalStore` ```js globalStore: { state: { tabs: [] } } ``` ### `storageData.json` ```js { "state": { "tabs": [] } } ``` ### `main` ```js async function onAppLoad () { await initRestoreLastState() ... } async function initRestoreLastState () { if (settings.startupAction == 'restore-last-state') { globalStore.state = await getStorageProperty('state') } } async function getStorageProperty (key) { return JSON.parse(getStorageData())[key] } function onExecuteCommand () { saveTabCommand() saveTabCwd() writeStateToStorage() ... } function saveTabCommand () { get(stateCurrentTab).commands.push(event.command) } function saveTabCwd () { get(stateCurrentTab).cwd = getCwdPath() } function onNewTab () { addTab(event) writeStateToStorage() ... } function addTab () { let tab = { cwd: '', commands: [] } tab.cwd = getCwdPath() globalStore.state.tabs.push(tab) } function writeStateToStorage () { if (settings.startupAction == 'restore-last-state') { // Avoid data corruption by writing data synchronously // (file might get corrupted when multiple async processes writing at the same time) writeStorageSync('state', globalStore.state) } } ... ```

claunia commented

@DHowett commented on GitHub (Oct 25, 2020):

@aleksey-hoffman we await your pull request! Thanks!

@DHowett commented on GitHub (Oct 25, 2020): @aleksey-hoffman we await your pull request! Thanks!

claunia commented

@zadjii-msft commented on GitHub (Oct 25, 2020):

If it'll only take a few hours to implement, then I look forward to the PR 😉

@zadjii-msft commented on GitHub (Oct 25, 2020): If it'll only take a few hours to implement, then I look forward to the PR 😉

claunia commented

@portexe commented on GitHub (Oct 25, 2020):

Can't wait for your PR! @aleksey-hoffman

@portexe commented on GitHub (Oct 25, 2020): Can't wait for your PR! @aleksey-hoffman

claunia commented

@aleksey-hoffman commented on GitHub (Oct 25, 2020):

@DHowett @zadjii-msft @portexe seriously, with the sarcasm, guys? I meant it would take you a few hours because you already know the structure of the project and how everything works. Obviously it would take me longer than that, because I would have to learn the whole codebase in order to not mess anything up. I'm busy working on my own stuff and don't have time to learn how this project works.

I've laid out the whole restoring logic for you above. At first, it doesn't have to be any more complex than this. I use a similar system in my own app and I know that it works perfectly. Just add some error handlers and adapt the logic to your codebase, and it's done.

If you are just going to take questions and advice with sarcasm, I don't really wanna participate

@aleksey-hoffman commented on GitHub (Oct 25, 2020): @DHowett @zadjii-msft @portexe seriously, with the sarcasm, guys? I meant it would take you a few hours because you already know the structure of the project and how everything works. Obviously it would take me longer than that, because I would have to learn the whole codebase in order to not mess anything up. I'm busy working on my own stuff and don't have time to learn how this project works. I've laid out the whole restoring logic for you above. At first, it doesn't have to be any more complex than this. I use a similar system in my own app and I know that it works perfectly. Just add some error handlers and adapt the logic to your codebase, and it's done. If you are just going to take questions and advice with sarcasm, I don't really wanna participate

claunia commented

@DHowett commented on GitHub (Oct 25, 2020):

@aleksey-hoffman it’s just... it’s generally considered poor form to find a feature request and gesticulate wildly about how “easy” it would be or how the maintainers are ignoring a common use case or something. We all want this feature! It’s just that we’ve spent the past year and change getting Terminal up and running and shippable before we come back and focus on the lower priority nice-to-haves.

Things like competent terminal emulation, performance and reliability, a UI people can understand, a robust configuration model, and a settings UI (popular request, even if some folks prefer JSON) have been prioritized ahead of other things like this and “well does the bold font actually look bold.”

In general, these decisions come down not to lack of knowledge or understanding of the problem space but of hours in the day for my team—which was up until quite recently only four people—to get work done. 😄

@DHowett commented on GitHub (Oct 25, 2020): @aleksey-hoffman it’s just... it’s generally considered poor form to find a feature request and gesticulate wildly about how “easy” it would be or how the maintainers are ignoring a common use case or something. We _all_ want this feature! It’s just that we’ve spent the past year and change getting Terminal up and running and shippable before we come back and focus on the lower priority nice-to-haves. Things like competent terminal emulation, performance and reliability, a UI people can understand, a robust configuration model, and a settings UI (popular request, even if some folks prefer JSON) have been prioritized ahead of other things like this and “well does the bold font actually look bold.” In general, these decisions come down not to lack of knowledge or understanding of the problem space but of hours in the day for my team—which was up until quite recently only four people—to get work done. 😄

claunia commented

@zadjii-msft commented on GitHub (Oct 25, 2020):

You've provided a gross over-simplification of how this feature would need to work. Let's break it down.

Figuring out the CWD of a process on windows is Hard. See #3158 and linked threads for an in-depth discussion of why.
Restoring just a list of entered commands - that's probably not what the user wants. The user wants the output in the buffer, probably in addition to the list of entered commands. However, the Terminal itself doesn't know what an "entered command" is. When the user has vim open, how would the Terminal differentiate that input from the input at the prompt line? The Terminal really can't which is why restoring command history is usually the responsibility of the shell application, not the Terminal.
The Terminal doesn't currently have a good way of storing runtime state like the globalStore you've mentioned above. We've been trying to avoid writing to the user's settings.json file, since that's been a minefield in the past, but that leaves us without a good way of storing non-user-facing application state. We've got #7972 open though tracking how we might want to do this in the future.
How do we handle restoring multiple windows? When you think about restoring tabs in a browser, it's usually about restoring all the windows with all the tabs, not just the tabs in a single window. We don't really have a "quit"-like feature that closes all the windows simultaneously, so you'd have to close the windows one at a time. When it comes time to restore the state of the window, that would just restore the last window you closed. We'd need some sort of cross-process communication to coordinate the saving/restoring of every window's state, which fortunately we're working on over in #5000
We haven't even gotten to mentioning pane state in addition to tab state. There's actually quite a bit of info we'll need per window/tab/pane - the terminal title, tab color, profile, split size and direction, etc.

All this together makes this feature a lot more work than just "a few hours", even for someone who's deeply familiar with the codebase. We're all very passionate about this project, and very excited to make it the best application we can, including this feature. Collaboration is a key part of that, and we're happy to accept community feedback and contributions. However, suggesting that something is something like this is "easy" is incredibly dismissive of all the hard work that is being done.

@zadjii-msft commented on GitHub (Oct 25, 2020): You've provided a gross over-simplification of how this feature would need to work. Let's break it down. 1. Figuring out the CWD of a process on windows is **H**ard. See #3158 and linked threads for an in-depth discussion of why. 2. Restoring just a list of entered commands - that's probably not what the user wants. The user wants the _output_ in the buffer, probably in addition to the list of entered commands. However, the Terminal itself doesn't know what an "entered command" is. When the user has `vim` open, how would the Terminal differentiate that input from the input at the prompt line? The Terminal really can't which is why restoring command history is usually the responsibility of the _shell_ application, not the Terminal. 3. The Terminal doesn't currently have a good way of storing runtime state like the `globalStore` you've mentioned above. We've been trying to avoid writing to the user's `settings.json` file, since that's been a minefield in the past, but that leaves us without a good way of storing non-user-facing application state. We've got #7972 open though tracking how we might want to do this in the future. 4. How do we handle restoring multiple windows? When you think about restoring tabs in a browser, it's usually about restoring all the windows with all the tabs, not just the tabs in a single window. We don't really have a "quit"-like feature that closes all the windows simultaneously, so you'd have to close the windows one at a time. When it comes time to restore the state of the window, that would just restore the last window you closed. We'd need some sort of cross-process communication to coordinate the saving/restoring of _every_ window's state, which fortunately we're working on over in #5000 5. We haven't even gotten to mentioning pane state in addition to tab state. There's actually quite a bit of info we'll need per window/tab/pane - the terminal title, tab color, profile, split size and direction, etc. All this together makes this feature a lot more work than just "a few hours", even for someone who's deeply familiar with the codebase. We're all very passionate about this project, and very excited to make it the best application we can, including this feature. Collaboration is a key part of that, and we're happy to accept community feedback and contributions. However, suggesting that something is something like this is "easy" is incredibly dismissive of all the hard work that is being done.

claunia commented

@aleksey-hoffman commented on GitHub (Oct 25, 2020):

@DHowett I get it, we have to prioritize, but I'd argue this feature is way more important / time saving / desirable than the features like "is bold text really bold".

@zadjii-msft I don't know mate, I feel like you are overcomplicating this a bit.

You're saying the commands cannot be distinguished when you're using vim, but I'm talking about regular commands, not all people use vim, and if you do, there are other ways to distinguish real commands, e.g. create a keydown listener and record key presses. The functions that paste text (ctrl + v and via mouse) can also record the commands (e.g. extracting it from the clipboard API).

Isn't there a workaround for this? Why would it even need to extract CWD from somewhere if all commands are entered in plain text? The app could just parse all entered commands and check if any of them change the directory e.g. doesChangeDir(['cd *', '.. *'], command). If the command changes directory e.g. cd C:\test, write it to storage and, on the next launch, run cd C:\. Would that not work?
I disagree, I think most users just want to re-open the app, press up-arrow a few times and press enter rather than typing the path of the project directory and all the commands manually every single time. And the support for buffers can be added later.
I don't see why creating a shared memory store is a problem, Create 1 file with 1 class for storing shared data. Create a single instance and import it in every file that needs it.
And as for the settings.json, I don't get the point. You are storing all user settings in settings.json but you don't want to store this particular user setting in there because there's already too many user settings? So opacity is good enough to be stored in there, but the launchAction is not, for some reason? That's what the file settings.json is for, is it not?
Okay, until you implement the IPC, create a function that sends all opened terminal processes taskkill /pid PROCESS_PID. Isn't that the same thing as closing the window manually by clicking on the X? If somehow Windows Terminal processes get closed forcefully even without the /f flag, then make this feature experimental and add a warning saying "all windows will get forcefully closed" before executing the function.
I don't see why it's a problem to store all the windows data on the drive and then restore it on launch. When a window is closed, do not delete that data so it can be restored on next launch. On the next launch, programmatically create all the windows, open all their tabs, and set all other data (panes, colors, etc):

@aleksey-hoffman commented on GitHub (Oct 25, 2020): @DHowett I get it, we have to prioritize, but I'd argue this feature is way more important / time saving / desirable than the features like "is bold text really bold". @zadjii-msft I don't know mate, I feel like you are overcomplicating this a bit. You're saying the commands cannot be distinguished when you're using `vim`, but I'm talking about regular commands, not all people use `vim`, and if you do, there are other ways to distinguish real commands, e.g. create a `keydown` listener and record key presses. The functions that paste text (ctrl + v and via mouse) can also record the commands (e.g. extracting it from the clipboard API). 1. Isn't there a workaround for this? Why would it even need to extract CWD from somewhere if all commands are entered in plain text? The app could just parse all entered commands and check if any of them change the directory e.g. `doesChangeDir(['cd *', '.. *'], command)`. If the command changes directory e.g. `cd C:\test`, write it to storage and, on the next launch, run `cd C:\`. Would that not work? 2. I disagree, I think most users just want to re-open the app, press `up-arrow` a few times and press `enter` rather than typing the path of the project directory and all the commands manually every single time. And the support for buffers can be added later. 3. I don't see why creating a shared memory store is a problem, Create 1 file with 1 class for storing shared data. Create a single instance and import it in every file that needs it. And as for the `settings.json`, I don't get the point. You are storing all user settings in `settings.json` but you don't want to store this particular user setting in there because there's already too many user settings? So opacity is good enough to be stored in there, but the `launchAction` is not, for some reason? That's what the file `settings.json` is for, is it not? 4. Okay, until you implement the IPC, create a function that sends all opened terminal processes `taskkill /pid PROCESS_PID`. Isn't that the same thing as closing the window manually by clicking on the X? If somehow Windows Terminal processes get closed forcefully even without the `/f` flag, then make this feature experimental and add a warning saying "all windows will get forcefully closed" before executing the function. 5. I don't see why it's a problem to store all the windows data on the drive and then restore it on launch. When a window is closed, do not delete that data so it can be restored on next launch. On the next launch, programmatically create all the windows, open all their tabs, and set all other data (panes, colors, etc):

claunia commented

@Sven65 commented on GitHub (Oct 27, 2020):

I look forward to this PR, it'd make it way easier to launch my development environment(s).

Maybe it should be looked at from the direction of the workspace feature in VSCode?

Something along the lines of a window per "workspace", containing the different terminals and their history?

@Sven65 commented on GitHub (Oct 27, 2020): I look forward to this PR, it'd make it way easier to launch my development environment(s). Maybe it should be looked at from the direction of the workspace feature in VSCode? Something along the lines of a window per "workspace", containing the different terminals and their history?

claunia commented

@zadjii-msft commented on GitHub (Oct 27, 2020):

The best way we have to prioritize features is based off of community feedback. Right now, the best way of tracking that is through reactions on issues - not the best metric, no, but definitely something measurable. Just sorting by 👍's, this issue is below 12 other requests, 5 of which we're hoping to get done in 2.0. This one just simply didn't make the cut.

The simple fact of the matter is that we have to design a solution that will work in all cases. If only 20% of people use VIM, and our heuristic for detecting commands doesn't work when the user is using VIM, that means that the solution just won't work in 20% of cases. That's not a solution - that's a hack, and not something we'd be comfortable shipping to our users.

Even if we did track all the key events sent to a terminal, there's no way of knowing if a particular set of keystrokes resulted in a changing of directory. There's just far too many things that could result in the directory changing - there's cd, pushd/popd, Set-Location for cmd & powershell, or the user could be using something like #keep, or something like FAR manager where the user is using arrow keys (or even the mouse!) to navigate the filesystem. That's without considering the use of text editors, or scenarios like WSL, docker, or ssh, where the path inside the distro/container/remote machine aren't the same as on the outside. There's just no way of doing this heuristically from input.
Fortunately, this isn't really an issue! Modern shells (read: not cmd.exe) all persist the command history themselves, so they'll all persist the history across reboots for you! The Terminal doesn't even need to get involved.
Okay, that's a fine opinion to have. See the above - the shell will restore the history for you, so that's why I don't think the command history is a valuable discussion to have.
It's not necessarily a problem, which is why the spec in #7972 is so incredibly straightforward. We don't want to be writing to the settings.json file, because in the past we've messed up the formatting of people's settings files, and people were greatly displeased with this, which is why we're introducing a second file to store this state. It's not terribly challenging, but this is just another piece of the puzzle that will take "a few hours" to implement, debug, write tests for, etc.
I'm pretty sure if we end up taskkill'ing all the Terminal processes, then none of them would have the chance to store the state of the open windows, entirely ruining any chance to restore the state of these open windows, and the whole point of the feature. I'd rather make sure that we implement this right the first time, rather than ship a half-baked hack and have people start taking a dependency on that behavior.
Before there's any sort of IPC way to coordinate between windows, how do we differentiate between the first launch of a Terminal window, and subsequent ones? Only the first launch should restore the state of the persisted windows, not the subsequent ones, right? You don't necessarily want each launch to pop up all the windows/tabs you had in the previous session (though, if you do, you might be interested in #756)

I'm looking forward to working on this, but it's probably not going to land until post 2.0. We're already going to have to work on serializing the state of a terminal tab as a part of #1256. Plus, we're already in the process of developing the IPC functionality as a part of #5000. So a lot of the hard problems that need to be solved before we can address this issue are already in progress!

(Frankly, most of this discussion is better off in #766 - this thread was supposed to specifically be the thread about restoring buffer contents, not window state)

@zadjii-msft commented on GitHub (Oct 27, 2020): The best way we have to prioritize features is based off of community feedback. Right now, the best way of tracking that is through reactions on issues - not the best metric, no, but definitely something measurable. Just sorting by 👍's, this issue is below 12 other requests, 5 of which we're hoping to get done in 2.0. This one just simply didn't make the cut. ![image](https://user-images.githubusercontent.com/18356694/97275760-54687600-1804-11eb-8218-49218b9b2a60.png) The simple fact of the matter is that we have to design a solution that will work in _all_ cases. If only 20% of people use VIM, and our heuristic for detecting commands doesn't work when the user is using VIM, that means that the solution just won't work in 20% of cases. That's not a solution - that's a hack, and not something we'd be comfortable shipping to our users. 1. Even if we did track all the key events sent to a terminal, there's _no way_ of knowing if a particular set of keystrokes resulted in a changing of directory. There's just far too many things that could result in the directory changing - there's `cd`, `pushd`/`popd`, `Set-Location` for cmd & powershell, or the user could be using something like [`#keep`](https://github.com/zadjii/keep), or something like FAR manager where the user is using arrow keys (or even the mouse!) to navigate the filesystem. That's without considering the use of text editors, or scenarios like WSL, docker, or ssh, where the path inside the distro/container/remote machine aren't the same as on the outside. There's just no way of doing this heuristically from input. Fortunately, this isn't really an issue! Modern shells (read: not `cmd.exe`) all persist the command history themselves, so they'll all persist the history across reboots _for you_! The Terminal doesn't even need to get involved. 2. Okay, that's a fine opinion to have. See the above - the shell will restore the history for you, so that's why I don't think the command history is a valuable discussion to have. 3. It's not necessarily a problem, which is why the spec in #7972 is so incredibly straightforward. We don't want to be _writing_ to the `settings.json` file, because in the past we've messed up the formatting of people's settings files, and people were greatly displeased with this, which is why we're introducing a second file to store this state. It's not terribly challenging, but this is just another piece of the puzzle that will take "a few hours" to implement, debug, write tests for, etc. 4. I'm pretty sure if we end up `taskkill`'ing all the Terminal processes, then none of them would have the chance to store the state of the open windows, entirely ruining any chance to restore the state of these open windows, and the _whole point of the feature_. I'd rather make sure that we implement this _right_ the first time, rather than ship a half-baked hack and have people start taking a dependency on that behavior. 5. Before there's any sort of IPC way to coordinate between windows, how do we differentiate between the _first_ launch of a Terminal window, and subsequent ones? Only the first launch should restore the state of the persisted windows, not the subsequent ones, right? You don't necessarily want each launch to pop up all the windows/tabs you had in the previous session (though, if you do, you might be interested in #756) I'm looking forward to working on this, but it's probably not going to land until post 2.0. We're already going to have to work on serializing the state of a terminal tab as a part of #1256. Plus, we're already in the process of developing the IPC functionality as a part of #5000. So a lot of the hard problems that need to be solved before we can address this issue are _already in progress_! (Frankly, most of this discussion is better off in #766 - this thread was supposed to specifically be the thread about _restoring buffer contents_, **not** window state)

claunia commented

@aleksey-hoffman commented on GitHub (Oct 27, 2020):

@zadjii-msft well, then I suppose my estimates of "a few hours" were off, I based it on my own experience, but I didn't consider the fact that in my app I already had the IPC, the system for writing to storage, etc. and, for some reason, I assumed that all of those systems were also already in place in the Windows Terminal. Thanks for clarification.

@aleksey-hoffman commented on GitHub (Oct 27, 2020): @zadjii-msft well, then I suppose my estimates of "a few hours" were off, I based it on my own experience, but I didn't consider the fact that in my app I already had the IPC, the system for writing to storage, etc. and, for some reason, I assumed that all of those systems were also already in place in the Windows Terminal. Thanks for clarification.

claunia commented

@111andre111 commented on GitHub (Oct 27, 2020):

@zadjii-msft
This is a very interesting information about the likes measurement.
Didn't know that one.
https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/sorting-issues-and-pull-requests

Just want to make folks aware of this other issue which is quite high in ranking already:
https://github.com/microsoft/terminal/issues/766
using the sort thumbs up emoji
https://github.com/microsoft/terminal/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc
So I have voted now for both as until this is done terminal is a cool project, but until that I need to stick with other projects like Babun, CMDer or Conemu, as at least just reopening my last opened tabs is quite essential for me as well otherwise I always need to remember what was last opened which is quite difficult sometimes for me when it comes to having open more than 20 tabs.

@111andre111 commented on GitHub (Oct 27, 2020): @zadjii-msft This is a very interesting information about the likes measurement. Didn't know that one. https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/sorting-issues-and-pull-requests Just want to make folks aware of this other issue which is quite high in ranking already: https://github.com/microsoft/terminal/issues/766 using the sort thumbs up emoji https://github.com/microsoft/terminal/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc So I have voted now for both as until this is done terminal is a cool project, but until that I need to stick with other projects like Babun, CMDer or Conemu, as at least just reopening my last opened tabs is quite essential for me as well otherwise I always need to remember what was last opened which is quite difficult sometimes for me when it comes to having open more than 20 tabs.

claunia commented

@zadjii-msft commented on GitHub (Oct 27, 2020):

For those looking for a workaround, I use an action like the following:

        { "command": { "action": "wt", "commandline": "new-tab --title OpenConsole cmd.exe /k #work 15 ; split-pane --title OpenConsole cmd.exe /k #work 15 ; split-pane -H cmd.exe /k media-commandline ; new-tab --title \"Symbols Script\" powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu 18.04\" ; new-tab -p \"microsoft/Terminal\" ; sp -V -p \"microsoft/Terminal\" ; sp -H -p \"microsoft/Terminal\" ; focus-tab -t 0" }, "name": "Good Morning" },

and then I invoke that from the command palette each morning after a Windows Update. That sets up the dev environment I usually use, with 4 tabs, and a bunch of panes in each. Customize as needed for your own profiles/environments. It's definitely not the same as "restore state" or "start with multiple tabs open", but it gets the job done.

@zadjii-msft commented on GitHub (Oct 27, 2020): For those looking for a workaround, I use an action like the following: ```json { "command": { "action": "wt", "commandline": "new-tab --title OpenConsole cmd.exe /k #work 15 ; split-pane --title OpenConsole cmd.exe /k #work 15 ; split-pane -H cmd.exe /k media-commandline ; new-tab --title \"Symbols Script\" powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu 18.04\" ; new-tab -p \"microsoft/Terminal\" ; sp -V -p \"microsoft/Terminal\" ; sp -H -p \"microsoft/Terminal\" ; focus-tab -t 0" }, "name": "Good Morning" }, ``` and then I invoke that from the command palette each morning after a Windows Update. That sets up the dev environment I usually use, with 4 tabs, and a bunch of panes in each. Customize as needed for your own profiles/environments. It's definitely not the same as "restore state" or "start with multiple tabs open", but it gets the job done.

claunia commented

@malxau commented on GitHub (Oct 27, 2020):

@zadjii-msft I don't think the shells can really restore command history in this case meaningfully. They can save command history, but once multiple tabs/panes are active, the shell has no idea which pane is which. The naive thing they'll do is terminate all the shells and all append to .bash_history etc in random order, and on restore each pane will have command history from all the other panes in an undefined order. I don't see how to do this without ascribing each tab/pane some form of identity, having shells persist state related to that identity, and communicating that identity back to the shell on restore.

If that identity did exist though, it would allow shells to save/restore things like the environment, current directory, aliases or other shell state, etc, which seems useful.

@malxau commented on GitHub (Oct 27, 2020): @zadjii-msft I don't think the shells can really restore command history in this case meaningfully. They can save command history, but once multiple tabs/panes are active, the shell has no idea which pane is which. The naive thing they'll do is terminate all the shells and all append to .bash_history etc in random order, and on restore each pane will have command history from all the other panes in an undefined order. I don't see how to do this without ascribing each tab/pane some form of identity, having shells persist state related to that identity, and communicating that identity back to the shell on restore. If that identity did exist though, it would allow shells to save/restore things like the environment, current directory, aliases or other shell state, etc, which seems useful.

claunia commented

2026-01-30 22:21:00 +00:00

@111andre111 commented on GitHub (Oct 27, 2020):

Saving a command history per tab isn't even what I would expect, because this is a very shell dependent behaviour.
Enough would be for me to recover the opened tabs plus ideally the saved last directory used in the particular tab.
My assumption is that now that we have the environment variables WT_PROFILE_ID and WT_SESSION.
That would be very enough already, as I am not expecting more from ConEmu.

So saving history per tab would already over scope of a beginning of this feature and in my opinion an enhancement already.

In my opinion writing this state to settings.json is not the right place.
Better would be something like SQLite or some alternative.

Thank you all for kicking this discussion off.

@111andre111 commented on GitHub (Oct 27, 2020): Saving a command history per tab isn't even what I would expect, because this is a very shell dependent behaviour. Enough would be for me to recover the opened tabs plus ideally the saved last directory used in the particular tab. My assumption is that now that we have the environment variables `WT_PROFILE_ID` and `WT_SESSION`. That would be very enough already, as I am not expecting more from ConEmu. So saving history per tab would already over scope of a beginning of this feature and in my opinion an enhancement already. In my opinion writing this state to settings.json is not the right place. Better would be something like SQLite or some alternative. Thank you all for kicking this discussion off.

claunia commented

@zadjii-msft commented on GitHub (Oct 27, 2020):

@malxau You're not wrong here. We're not the first terminal emulator that's allowed multiple concurrent instances, however, so I'm thinking that this is more of an issue that shells just simply haven't found the right solution for yet. We've got the WT_SESSION variable that we use for terminal instances, though I wouldn't want anyone taking a dependency on anything like that, especially considering it wouldn't work in something like tmux. If there was a way of identifying unique terminal instances that worked across emulators and shells to help coordinate the restoring of history to the correct terminal instance, I'd be all ears 😄

@zadjii-msft commented on GitHub (Oct 27, 2020): @malxau You're not wrong here. We're not the first terminal emulator that's allowed multiple concurrent instances, however, so I'm thinking that this is more of an issue that shells just simply haven't found the right solution for yet. We've got the `WT_SESSION` variable that we use for terminal instances, though I wouldn't want anyone taking a dependency on anything like that, especially considering it wouldn't work in something like `tmux`. If there was a way of identifying unique terminal instances that worked across emulators and shells to help coordinate the restoring of history to the correct terminal instance, I'd be all ears 😄

claunia commented

2026-01-30 22:21:00 +00:00

@Cisien commented on GitHub (Nov 19, 2020):

Speaking for myself, I would be happy if the terminal app just remembered and restored the tabs and separate processes (including elevation state with prompt). The buffer isn't important to me.

@Cisien commented on GitHub (Nov 19, 2020): Speaking for myself, I would be happy if the terminal app just remembered and restored the tabs and separate processes (including elevation state with prompt). The buffer isn't important to me.

claunia commented

2026-01-30 22:21:00 +00:00

@sarim commented on GitHub (Jan 13, 2021):

Huh, comments above reminds me of myself ~15yrs ago, when I thought I can do everything easily :P

Kidding aside, This issue seems to be describing multiple features together. Maybe it should be broken down into smaller parts and implemented one by one. Saving state, buffer, command list etc... doesn't seem necessary to me and maybe pushed further down the list.

First implementation should be just saving [{guid: cwd}].

First issue is to get CWD from both WSL linux shells and from windows shells. Conemu and Mintty relies on Escape codes from PROMPT to get it. Relevant conemu doc link

This is what I do in my bashrc.

PS1="$PS1\[\e]9;9;\"\$(wslpath -aw .)\"\007\e]9;12\007\]"

I guess Windows Terminal needs to do the same. Although I have no idea how multiple windows should be handled. I never open my terminal in multiple tabs in multiple windows :P

If extension support (#4000) was here, I might've tried to make an extension that listens to that ANSI Escape code and generates a command line with tabs and CWD.

@sarim commented on GitHub (Jan 13, 2021): Huh, comments above reminds me of myself ~15yrs ago, when I thought I can do everything easily :P Kidding aside, This issue seems to be describing multiple features together. Maybe it should be broken down into smaller parts and implemented one by one. Saving state, buffer, command list etc... doesn't seem necessary to me and maybe pushed further down the list. First implementation should be just saving `[{guid: cwd}]`. First issue is to get CWD from both WSL linux shells and from windows shells. Conemu and Mintty relies on Escape codes from PROMPT to get it. Relevant [conemu doc link](https://conemu.github.io/en/ShellWorkDir.html#connector-ps1) This is what I do in my bashrc. ``` PS1="$PS1\[\e]9;9;\"\$(wslpath -aw .)\"\007\e]9;12\007\]" ``` I guess Windows Terminal needs to do the same. Although I have no idea how multiple windows should be handled. I never open my terminal in multiple tabs in multiple windows :P If extension support (#4000) was here, I might've tried to make an extension that listens to that ANSI Escape code and generates a command line with tabs and CWD.

claunia commented

2026-01-30 22:21:01 +00:00

@nmoinvaz commented on GitHub (Jan 13, 2021):

I would like to mention that these features don't have to be supported for all shells. It would be okay to say, support some of them only for PowerShell, where certain information can be more easily obtained to make the feature work.

@nmoinvaz commented on GitHub (Jan 13, 2021): I would like to mention that these features don't have to be supported for all shells. It would be okay to say, support some of them only for PowerShell, where certain information can be more easily obtained to make the feature work.

claunia commented

2026-01-30 22:21:01 +00:00

@mingwandroid commented on GitHub (Feb 15, 2021):

I agree that saving and restoring state is very complicated and I'd not like to attempt to implement it.

However, I think an "undo close tab/window" function with a grace period could be implemented much more simply. You just keep everything running for the grace period and if an "undo close" event happens you just recreate the graphical components.

I know I said "just" a lot, and of course it'd be difficult work, still I think this would be a hugely useful feature for those of us who hit "close window" by mistake and I believe the end result (processes still running, ssh connections active etc) is a better end result (for this use-case).

Cheers.

@mingwandroid commented on GitHub (Feb 15, 2021): I agree that saving and restoring state is very complicated and I'd not like to attempt to implement it. However, I think an "undo close tab/window" function with a grace period could be implemented much more simply. You just keep everything running for the grace period and if an "undo close" event happens you just recreate the graphical components. I know I said "just" a lot, and of course it'd be difficult work, still I think this would be a hugely useful feature for those of us who hit "close window" by mistake and I believe the end result (processes still running, ssh connections active etc) is a better end result (for this use-case). Cheers.

claunia commented

2026-01-30 22:21:01 +00:00

@christophe-calmejane commented on GitHub (Apr 15, 2021):

@zadjii-msft

The best way we have to prioritize features is based off of community feedback. Right now, the best way of tracking that is through reactions on issues - not the best metric, no, but definitely something measurable. Just sorting by 👍's, this issue is below 12 other requests, 5 of which we're hoping to get done in 2.0. This one just simply didn't make the cut.

(Frankly, most of this discussion is better off in #766 - this thread was supposed to specifically be the thread about restoring buffer contents, not window state)

That's where you see the limit of using 👍's as a metric to sort priorities :)
Some features are hard to clearly express (for the end-user) and even harder to specify for the developer. Took me a bit to find this thread, just to realize after having read it all the way... that it's not the one to thumb up.

Like most people, all I need is Terminal to restore all my open tabs and their CWD (don't even need the last commands) when windows decides to reboot my computer for some updates, so I can resume my work as fast as possible with the usual 10 tabs (10 different folders) I've open during my daily sessions. A feature that most Terminal apps (especially on macOS) have.
Maybe start simple with just the last tabs (opt-in like Chrome) and associated CWD, and later add buffers, commands,... as option.

@christophe-calmejane commented on GitHub (Apr 15, 2021): @zadjii-msft > The best way we have to prioritize features is based off of community feedback. Right now, the best way of tracking that is through reactions on issues - not the best metric, no, but definitely something measurable. Just sorting by 👍's, this issue is below 12 other requests, 5 of which we're hoping to get done in 2.0. This one just simply didn't make the cut. > (Frankly, most of this discussion is better off in #766 - this thread was supposed to specifically be the thread about _restoring buffer contents_, **not** window state) That's where you see the limit of using 👍's as a metric to sort priorities :) Some features are hard to clearly express (for the end-user) and even harder to specify for the developer. Took me a bit to find this thread, just to realize after having read it all the way... that it's not the one to thumb up. Like most people, all I need is Terminal to restore all my open tabs and their CWD (don't even need the last commands) when windows decides to reboot my computer for some updates, so I can resume my work as fast as possible with the usual 10 tabs (10 different folders) I've open during my daily sessions. A feature that most Terminal apps (especially on macOS) have. Maybe start simple with just the last tabs (opt-in like Chrome) and associated CWD, and later add buffers, commands,... as option.

claunia commented

2026-01-30 22:21:02 +00:00

@steelx commented on GitHub (Apr 16, 2021):

is there any solution on this ? atleast remember 1 tab ?

@steelx commented on GitHub (Apr 16, 2021): is there any solution on this ? atleast remember 1 tab ?

claunia commented

2026-01-30 22:21:02 +00:00

@zadjii-msft commented on GitHub (Apr 16, 2021):

Nope, there aren't any updates yet. When there are, we'll make sure to post here. In the meantime, might I recommend the Subscribe button?

That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

We're working on storing "application state" over in #8771, which is one of the prerequisites for doing this.

For reference, I workaround this with a command in the command palette. I like to do like the following each time I boot up the Terminal in the morning:

{ "command": { "action": "wt", "commandline": "new-tab --title OpenConsole cmd.exe /k #work 15 ; split-pane -s .30 --title OpenConsole cmd.exe /k #work 15 ; split-pane  -s .25 -H cmd.exe /k media ; new-tab --title \"Symbols Script\" powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu 18.04\" ; new-tab -p \"microsoft/Terminal\" ; sp -V -p \"microsoft/Terminal\" ; sp -H -p \"microsoft/Terminal\" ; focus-tab -t 0" }, "name": "Good Morning" },

(you could probably make it shorter by replacing new-tab/split-pane with nt/sp, respectively).

I add that to the keybindings/actions. This creates a new command in the Command Palette named "Good Morning". That opens up a few tabs & panes, running various build environments. I like having it in a command rather than startupActions, because I only really want this in one terminal window, not every single one I launch. It's personal taste.

You could repeat this for multiple different "session"s if you wanted. That way you could have layouts pre-defined for various different dev environments.

We're also tracking adding commands to the new tab dropdown in #1571.

@zadjii-msft commented on GitHub (Apr 16, 2021): Nope, there aren't any updates yet. When there are, we'll make sure to post here. In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️ We're working on storing "application state" over in #8771, which is one of the prerequisites for doing this. <hr> For reference, I workaround this with a command in the command palette. I like to do like the following each time I boot up the Terminal in the morning: ```json { "command": { "action": "wt", "commandline": "new-tab --title OpenConsole cmd.exe /k #work 15 ; split-pane -s .30 --title OpenConsole cmd.exe /k #work 15 ; split-pane -s .25 -H cmd.exe /k media ; new-tab --title \"Symbols Script\" powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu 18.04\" ; new-tab -p \"microsoft/Terminal\" ; sp -V -p \"microsoft/Terminal\" ; sp -H -p \"microsoft/Terminal\" ; focus-tab -t 0" }, "name": "Good Morning" }, ``` (you could probably make it shorter by replacing `new-tab`/`split-pane` with `nt`/`sp`, respectively). I add that to the `keybindings`/`actions`. This creates a new command in the [Command Palette](https://docs.microsoft.com/en-us/windows/terminal/command-palette) named "Good Morning". That opens up a few tabs & panes, running various build environments. I like having it in a command rather than `startupActions`, because I only really want this in _one_ terminal window, not _every single one I launch_. It's personal taste. You could repeat this for multiple different "session"s if you wanted. That way you could have layouts pre-defined for various different dev environments. We're also tracking adding commands to the new tab dropdown in #1571.

claunia commented

2026-01-30 22:21:02 +00:00

@soroshsabz commented on GitHub (Jun 4, 2021):

I think session functionality and management is very beyond than session restoration, and I think Windows Terminal must have focus to design and implement great session concept and functionalities about that, like tmux (#10331).

I think it is important to make session is umbrella for all features in terminal like

panes
tabs
configuration
short key
etc.

@soroshsabz commented on GitHub (Jun 4, 2021): I think session functionality and management is very beyond than session restoration, and I think Windows Terminal must have focus to design and implement great session concept and functionalities about that, like [tmux](https://github.com/tmux/tmux) (#10331). I think it is important to make session is umbrella for all features in terminal like * panes * tabs * configuration * short key * etc.

claunia commented

@MarkIngramUK commented on GitHub (Jun 4, 2021):

I would settle for remembering which tabs were open, what their custom titles were, and what their custom colours were. A bonus would be the current directories in each shell, but the main thing that annoys me is having to restart my machine for whatever reason, then open Terminal, re-open my tabs, rename my tabs, apply colours to my tabs...

@MarkIngramUK commented on GitHub (Jun 4, 2021): I would settle for remembering which tabs were open, what their custom titles were, and what their custom colours were. A bonus would be the current directories in each shell, but the main thing that annoys me is having to restart my machine for whatever reason, then open Terminal, re-open my tabs, rename my tabs, apply colours to my tabs...

claunia commented

@rf-0 commented on GitHub (Aug 7, 2021):

How come emoji support is #2...? I guess I'm missing its use case...

It sounds like this feature would be more important than quite a few from that list. Also, agree with @MarkIngramUK

@rf-0 commented on GitHub (Aug 7, 2021): How come emoji support is #2...? I guess I'm missing its use case... It sounds like this feature would be more important than quite a few from that list. Also, agree with @MarkIngramUK

claunia commented

@ykoehler commented on GitHub (Oct 15, 2021):

In the same idea, I would like to be able to "obtain" the wt command to execute to open up my tab exactly the same way (with same panes and panes size, etc). From there I could paste that into an shortcut icon and create different layout for each icons to open with. So if somehow we could dump a wt command output that I re-run and get a window with same tab/pane and size that would be appreciated, in this case, I do not care about running command in those, but I get you would have to support it.

@ykoehler commented on GitHub (Oct 15, 2021): In the same idea, I would like to be able to "obtain" the wt command to execute to open up my tab exactly the same way (with same panes and panes size, etc). From there I could paste that into an shortcut icon and create different layout for each icons to open with. So if somehow we could dump a wt command output that I re-run and get a window with same tab/pane and size that would be appreciated, in this case, I do not care about running command in those, but I get you would have to support it.

claunia commented

@Darkster1 commented on GitHub (Oct 25, 2021):

What to do if a terminal closed, but left the session running (cmd.exe + subprocess) the application status is perfectly 'running' but the parent window from cmd.exe disapeared (for some reason it asked, close all tabs?, clicked cancel, a moment later terminal was gone but processes still UP) and they're actually still up noticing a WT_SESSION in processExplorer but how to reconnect (the settings are probably ignored).

@Darkster1 commented on GitHub (Oct 25, 2021): What to do if a terminal closed, but left the session running (cmd.exe + subprocess) the application status is perfectly 'running' but the parent window from cmd.exe disapeared (for some reason it asked, close all tabs?, clicked cancel, a moment later terminal was gone but processes still UP) and they're actually still up noticing a WT_SESSION in processExplorer but how to reconnect (the settings are probably ignored).

claunia commented

@gerhard4 commented on GitHub (Feb 15, 2023):

I'm surprised that nobody has mentioned that yet, but iTerm2 for macOS does pretty much what one would expect from such a feature. It's one of the very few things that I miss from the Mac on Windows. The GitHub project: https://github.com/gnachman/iTerm2

@gerhard4 commented on GitHub (Feb 15, 2023): I'm surprised that nobody has mentioned that yet, but [iTerm2](https://iterm2.com/) for macOS does pretty much what one would expect from such a feature. It's one of the very few things that I miss from the Mac on Windows. The GitHub project: https://github.com/gnachman/iTerm2

claunia commented

@111andre111 commented on GitHub (Feb 16, 2023):

Now I am not really an OS specialist, but I think iTerm2 is not really a good example as it goes back to macOS which basically only has to hold sessions that go back either to zsh or bash. I think Terminal has to fill much more gaps because under a Windows there is an extremely broad spectrum of terminal sessions possible starting from MinGW sessions, Cygwin sessions, bash sessions, Powershell sessions, CMD sessions (which even don't really have a state and you would need to work around lots of things if it's even possible to save the CMD buffer separately). So I think that request is a whole other beast than what iTerm2 has to fulfill.

For Windows you need to compare to a completely other set of shells like e.g. Babun which has been discontinued, cmder or MobaXterm. Lots of these shells base on the initial work that has been done with ConEmu. If you look to all these shell's issue collections you will find out that there have been happening lots of struggles around lots of issues. And the chorus is that some of these shells specialized only on a possible subset of possible shells like e.g. Cygwin sessions or SSH sessions....

Please correct me if I am wrong.

@111andre111 commented on GitHub (Feb 16, 2023): Now I am not really an OS specialist, but I think iTerm2 is not really a good example as it goes back to macOS which basically only has to hold sessions that go back either to zsh or bash. I think Terminal has to fill much more gaps because under a Windows there is an extremely broad spectrum of terminal sessions possible starting from MinGW sessions, Cygwin sessions, bash sessions, Powershell sessions, CMD sessions (which even don't really have a state and you would need to work around lots of things if it's even possible to save the CMD buffer separately). So I think that request is a whole other beast than what iTerm2 has to fulfill. For Windows you need to compare to a completely other set of shells like e.g. Babun which has been discontinued, cmder or MobaXterm. Lots of these shells base on the initial work that has been done with ConEmu. If you look to all these shell's issue collections you will find out that there have been happening lots of struggles around lots of issues. And the chorus is that some of these shells specialized only on a possible subset of possible shells like e.g. Cygwin sessions or SSH sessions.... Please correct me if I am wrong.

claunia commented

@gerhard4 commented on GitHub (Feb 16, 2023):

I know that I don't know enough -- by a long shot -- to correct you or to tell you that you're wrong :)

However, sometimes perfect can be the enemy of good (or better). Tools that have to work with a multitude of environments sometimes support features only for a subset of supported environments. If Terraform, for example, only supported features that are supported by all cloud environments it supports, it would not be very useful. Sometimes it makes sense to support features only for a subset of supported environments. In this case, if it can be done, say, for Bash and PowerShell, that would be a huge win for many if not most (or even an overwhelming majority of) users.

(FWIW, iTerm2 supports tcsh, zsh, bash, and fish.)

@gerhard4 commented on GitHub (Feb 16, 2023): I know that I don't know enough -- by a long shot -- to correct you or to tell you that you're wrong :) However, sometimes perfect can be the enemy of good (or better). Tools that have to work with a multitude of environments sometimes support features only for a subset of supported environments. If Terraform, for example, only supported features that are supported by all cloud environments it supports, it would not be very useful. Sometimes it makes sense to support features only for a subset of supported environments. In this case, if it can be done, say, for Bash and PowerShell, that would be a huge win for many if not most (or even an overwhelming majority of) users. (FWIW, iTerm2 supports tcsh, zsh, bash, and fish.)

claunia commented

@christophe-calmejane commented on GitHub (Feb 16, 2023):

Agreed!
Only support for bash/powershell is enough for me (for now).
It really is a pain when windows decides to reboot by itself (crash, update, ...) and I loose the 10 shells I have opened because I work on many projects at the same time.
On the other hand, when my mac reboots, I always get back right where I was.

Please consider partial support.

@christophe-calmejane commented on GitHub (Feb 16, 2023): Agreed! Only support for bash/powershell is enough for me (for now). It really is a pain when windows decides to reboot by itself (crash, update, ...) and I loose the 10 shells I have opened because I work on many projects at the same time. On the other hand, when my mac reboots, I always get back right where I was. Please consider partial support.

claunia commented

@mmseng commented on GitHub (Oct 22, 2023):

Just expressing my use case: As an IT Pro, I frequently have 8-10 PowerShell 5.1 or 7+ tabs open in terminal. I don't "pre-plan" what's going to happen in these tabs, and I don't waste time customizing each tab with titles or colors. I just open them as I need them to work on different tasks/projects in parallel. So "losing" the content of these tabs when I come back to my PC when either the PC has restarted for Windows updates, or Terminal has mysteriously restarted (I assume for a forced update of some sort?) is very disruptive.

All of this would be solved (for me personally) if only the buffer contents would be restored, as I could easily look and see what I was doing last in each tab and what the most recent command output was. To a lesser degree, restoring the tab's "local" command history would suffice as well, as I could then just use the up arrow to see what the last command was in any given tab.

Currently when these Terminal restarts happen, the number, position, and client of each tab are successfully restored, but that is not enough to get me back on track. Ostensibly I could manually customize the title of every tab just in case this happens, which might help a little, but even then it wouldn't tell me exactly what I was doing in that tab or what state I had left that tab's task in. Plus, during a work day I will have opened and closed dozens (maybe hundreds) of tabs, so customizing tabs just in case would be a huge waste of time. Restoration of the buffer/command history is really what's needed.

@mmseng commented on GitHub (Oct 22, 2023): Just expressing my use case: As an IT Pro, I frequently have 8-10 PowerShell 5.1 or 7+ tabs open in terminal. I don't "pre-plan" what's going to happen in these tabs, and I don't waste time customizing each tab with titles or colors. I just open them as I need them to work on different tasks/projects in parallel. So "losing" the content of these tabs when I come back to my PC when either the PC has restarted for Windows updates, or Terminal has mysteriously restarted (I assume for a forced update of some sort?) is very disruptive. All of this would be solved (for me personally) if only the buffer contents would be restored, as I could easily look and see what I was doing last in each tab and what the most recent command output was. To a lesser degree, restoring the tab's "local" command history would suffice as well, as I could then just use the up arrow to see what the last command was in any given tab. Currently when these Terminal restarts happen, the number, position, and client of each tab are successfully restored, but that is not enough to get me back on track. Ostensibly I could manually customize the title of every tab _just in case_ this happens, which might help a little, but even then it wouldn't tell me exactly what I was doing in that tab or what state I had left that tab's task in. Plus, during a work day I will have opened and closed dozens (maybe hundreds) of tabs, so customizing tabs _just in case_ would be a huge waste of time. Restoration of the buffer/command history is really what's needed.

claunia commented

@gerhard4 commented on GitHub (Oct 22, 2023):

Re mmseng's comment:

Restoration of the buffer/command history is really what's needed.

For me, it's more the buffer than the command history. The buffer contains the output and the commands. If the output of a command changed over time, rerunning the commands might not help getting the information back about what happened.

Lateral thought: an on-disk rotating buffer with a maximum lifetime (24h? configurable?) on disk for every tab that contains everything visible on screen would be helpful, too, and would give me most of what the feature of this issue could give me.

@gerhard4 commented on GitHub (Oct 22, 2023): Re [mmseng's comment](https://github.com/microsoft/terminal/issues/961#issuecomment-1774196142): > Restoration of the buffer/command history is really what's needed. For me, it's more the buffer than the command history. The buffer contains the output and the commands. If the output of a command changed over time, rerunning the commands might not help getting the information back about what happened. Lateral thought: an on-disk rotating buffer with a maximum lifetime (24h? configurable?) on disk for every tab that contains everything visible on screen would be helpful, too, and would give me most of what the feature of this issue could give me.

claunia commented

@mmseng commented on GitHub (Oct 23, 2023):

it's more the buffer than the command history

Wholeheartedly agreed. The buffer is far more important; I would even go so far as to call it precious.

At the risk of repeating drama from above, from an outside perspective, either item seems relatively simple (compared to something like preservation of state), as both buffer and command history are mostly just plain text and the rendering thereof. The command history implementation already even lends itself to this purpose, since you can technically manually edit it.

I know it's always way more complicated than it seems; I only mentioned the above because, as much as I'd like to see this implemented for the good of all, I would personally be willing to implement a custom solution that, at the very least, dumped buffer history to a file along with some sort of identifier as to the tab it belonged to (e.g. name the file after the tab title and date), if it allowed me to recover my work in these instances. Of course, I would have no idea how to develop such a hack myself, and the logic for when to dump that data does not immediately come to mind.

@mmseng commented on GitHub (Oct 23, 2023): > it's more the buffer than the command history Wholeheartedly agreed. The buffer is far more important; I would even go so far as to call it precious. At the risk of repeating drama from above, from an outside perspective, either item seems relatively simple (compared to something like preservation of state), as both buffer and command history are mostly just plain text and the rendering thereof. The command history implementation already even lends itself to this purpose, since you can technically manually edit it. I know it's always way more complicated than it seems; I only mentioned the above because, as much as I'd like to see this implemented for the good of all, I would personally be willing to implement a custom solution that, at the very least, dumped buffer history to a file along with some sort of identifier as to the tab it belonged to (e.g. name the file after the tab title and date), if it allowed me to recover my work in these instances. Of course, I would have no idea how to develop such a hack myself, and the logic for _when_ to dump that data does not immediately come to mind.

claunia commented

@plutonium-239 commented on GitHub (Jan 8, 2024):

Is this being worked on?
I see that PR #8771 was opened in 2021 but then it got closed without a reason? (last comment was just a discussion on changes)

@plutonium-239 commented on GitHub (Jan 8, 2024): Is this being worked on? I see that PR #8771 was opened in 2021 but then it got closed without a reason? (last comment was just a discussion on changes)

claunia commented

@zadjii-msft commented on GitHub (Jan 8, 2024):

Yep, I believe @lhecker's been working on this for a bit now.

#8771 was more specifically a PR to implement #766. This issue is more specifically "restore buffer contents", while #766 was more generally "restore various elements of the Terminal's state".

#8771 ended up resurrected as #10513 which then was used by #10972 to store the window position, size (but notably, not the buffer content)

@zadjii-msft commented on GitHub (Jan 8, 2024): Yep, I believe @lhecker's been working on this for a bit now. #8771 was more specifically a PR to implement #766. This issue is more specifically "restore buffer contents", while #766 was more generally "restore various elements of the Terminal's state". #8771 ended up resurrected as #10513 which then was used by #10972 to store the window position, size (but notably, not the buffer content)

claunia commented

@soroshsabz commented on GitHub (Mar 29, 2024):

@zadjii-msft Did you know how to use this feature?

@soroshsabz commented on GitHub (Mar 29, 2024): @zadjii-msft Did you know how to use this feature?

claunia commented

@zadjii-msft commented on GitHub (Mar 29, 2024):

This only just merged hours ago, so it's not available yet outside of just building the code from main directly. Tonight's canary build should have this, though, our canary pipeline has been having some publishing issues this week.

It should be enabled if you have "firstWindowPreference": "persistedWindowLayout" enabled in your settings.

@zadjii-msft commented on GitHub (Mar 29, 2024): This only just merged hours ago, so it's not available yet outside of just building the code from `main` directly. Tonight's canary build _should_ have this, though, our canary pipeline has been having some publishing issues this week. It should be enabled if you have `"firstWindowPreference": "persistedWindowLayout"` enabled in your settings.

claunia commented

@ylluminate commented on GitHub (Jun 13, 2024):

Is this supposed to be available in 1.20.11381.0? When I have the "firstWindowPreference": "persistedWindowLayout" set, I still lose buffer / tab history upon restart, even though it does restart the sessions... My expectation from the parent request is that all of my history for various shells from PowerShell and cmd.exe to Ubuntu 24.04, etc. is all retained in perpetuity between Windows Terminal restarts...

@ylluminate commented on GitHub (Jun 13, 2024): Is this supposed to be available in 1.20.11381.0? When I have the `"firstWindowPreference": "persistedWindowLayout"` set, I still lose buffer / tab history upon restart, even though it does restart the sessions... My expectation from the parent request is that all of my history for various shells from PowerShell and cmd.exe to Ubuntu 24.04, etc. is all retained in perpetuity between Windows Terminal restarts...

claunia commented

@zadjii-msft commented on GitHub (Jun 13, 2024):

Nope. This was added in 1.21.

@zadjii-msft commented on GitHub (Jun 13, 2024): Nope. This was added in 1.21.

claunia commented

@mmseng commented on GitHub (Jun 13, 2024):

I've been using it in the 1.21 Windows Terminal Preview. It does work as expected (for a certain definition of expected), however the vast majority of the times when I need it is when Windows updates reboot the machine, or when the machine otherwise reboots while Terminal is open, and from what I've seen I don't believe it's been working in these cases (I haven't been tracking it closely enough to make a more confident statement). As I recall, the failure due to Windows update reboots is an open issue.

@mmseng commented on GitHub (Jun 13, 2024): I've been using it in the 1.21 Windows Terminal Preview. It does work as expected ([for a certain definition of expected](https://github.com/microsoft/terminal/issues/17274)), however the vast majority of the times when I need it is when Windows updates reboot the machine, or when the machine otherwise reboots while Terminal is open, and from what I've seen I don't believe it's been working in these cases (I haven't been tracking it closely enough to make a more confident statement). As I recall, the failure due to Windows update reboots is an open [issue](https://github.com/microsoft/terminal/issues/17179).

claunia commented

@edswangren commented on GitHub (Sep 10, 2024):

this thread is so Windows. I don't mean to throw any shade at the devs and designers here, it's just that feeling of "@#(^#@^&" when my OS knocks me down with nagging and unwanted reboots only to hit me again by stealing more of my time, for years and years while my macs have never once hurt me this way. My mac picks me up when I'm down (<3 u my silver fox)

But seriously the comment above regarding that bastard known as perfection is 100% right. I mean, at least you can stop worrying about privacy, right? we've all used 11.

...well thanks for the hard work, that should serve as catharsis for now.

@edswangren commented on GitHub (Sep 10, 2024): this thread is so Windows. I don't mean to throw any shade at the devs and designers here, it's just that feeling of "@#(^#@^&" when my OS knocks me down with nagging and unwanted reboots only to hit me again by stealing more of my time, for years and years while my macs have never once hurt me this way. My mac picks me up when I'm down (<3 u my silver fox) But seriously the comment above regarding that bastard known as perfection is 100% right. I mean, at least you can stop worrying about privacy, right? we've all used 11. ...well thanks for the hard work, that should serve as catharsis for now.

claunia commented

@aschekatihin commented on GitHub (May 17, 2025):

There should be ability to opt out of this behavior in settings. It is a bit distracting least to say.

@aschekatihin commented on GitHub (May 17, 2025): There should be ability to opt out of this behavior in settings. It is a bit distracting least to say. ![Image](https://github.com/user-attachments/assets/31483086-e127-4ef3-a6b5-fa72364d4132)

claunia commented