Fair request.

+1

Not sure about the scope of this issue, but I have a related problem. Let me know if I should report it in a separate issue.

If I have multiple projects open in VS Code (e.g. 2 separate windows, each with a folder loaded) and I restart VS Code (e.g. due to an update), only the last project that was opened gets automatically reloaded.

I think it should be on VS Code to completely restore the UI state after a restart. Chrome, for example, does this--it reloads both the correct number of windows, as well as the correct tabs within each window.

I understand from the discussion in #264 that there is some issue with restoring state for standalone files that are opened (as opposed folders), but in my case it was 2 folders that were open.

I'm running Code 0.10.3 on OS X.

@nchammas you can enable restoring of all windows through the window.reopenFolders setting. Set it to all and you should be all set.

Oh snap. Good call--that did the job. 👍

So if no folders are open, opened files are not reopened after restart VSC? A bit dumb.

Yes, only if you open a folder we remember all UI state.

I've been bit by this already several times, as a reload (from an extension update) loses all my non-workspace-associated open files. It's kind of driving me crazy, as extension updates are very frequent.

I understand the association with workspaces, but I am also using vscode a lot as a "regular" text editor, calling it up from the cmd line to open files all over my filesystem. It's a fantastic general-purpose editor in addition to a project-oriented IDE, but this issue gets in the way of that usage pattern.

Thinking out loud possible solutions: how about having a "mock" workspace, tied to a special internal name (not on the filesystem) that would simply record all open paths as absolute? This would be the "dump bucket" for all other open files, and could be restored as a group. I'd be OK if the restored individual files, on reopen, all get sent to a single window (to avoid the complexities of tracking them per-window).

Just a thought. In any case, great job overall with VSCode, I'm loving it!

Duplicate: #101

@ranjan-ranjan not technically, this however will probably be a pre-requisite to hot-exit (#101) working for empty workspaces #13733

Right now folder workspaces record the state of the editors in local storage under the storage://workspace/<path>/memento/workbench.editors.files.textfileeditor key.

Empty workspaces have a similar prefix in local storage: storage://workspace/__$noWorkspace__memento/, but workbench.editors.files.textfileeditor is not recorded. This is likely the case because there is only a single empty workspace key and multiple windows writing that sort of data to the same key would be very messy. It's also noteworthy to call out there is no slash after __$noWorkspace__, I imagine this was an oversight in the original implementation.

One solution for enabling this is to generate a random hash to be known as the workspace identifier and move the workspace storage to ``storage://workspace/$noWorkspace//. Evicting the entries would be the main difference to folder workspaces as they only need to be retained if there are backups to restore or if "window.reopenFolders": "all"` is set.

Making IWorkspace exist for empty workspaces, putting the ID in IWorkspace.uid and making IWorkspace.resource optional could be done to accomplish this, this would probably have a lot of associated changes required that currently rely on IWorkspaceContextService.getWorkspace being falsy to check if it's an empty workspace.

@bpasero is this the approach you would take? Any details I'm missing about the current situation?

/cc @chrmarti (interest)

Well you take workbench.editors.files.textfileeditor as the UI state, but the reality is that there are an unlimited number of more UI state keys that contribute to the overall UI state. One reason for not supporting this is the fact that you can have multiple windows without workspace associated and then you need to start inventing identifiers.

We should also not forget that the majority of users actually likes the fact that the window opens empty. I remember once that I was always restoring the previously opened file (even for empty workspaces) and that caused an outrage by people that hated it.

Since restoring previously opened files when opening on a folder is accepted as the right thing to do, there should be a large number of users who would prefer the same without opening on a folder. Did removal of that not trigger any reactions? I still feel we don't necessarily understand the not-open-on-folder case well, because we tend to not use it that way.

@chrmarti The behavior was never present.

The use case is simple: remember (all) UI state when opening VSC, independent of the open number of folders/workspaces.

@chrmarti all I can say is that we once had a bug where we would always reopen the last used file even in the empty workspace case and I got lots of issues for such behaviour. I agree that it is hard to say if that is the majority. Though I must also say that this does not seem one of the highest voted issues so far, so maybe people got used to it.

My point is about changing the default behaviour we have today should be a decision with great care.

@bpasero reopening the last file and not the rest is a little different to restoring the entire state. Here is how some other editors work for this case:

• Sublime: Always restore the previous state when a folder is not opened.
• Atom (1.11.2): When you open a file in Atom the folder is automatically added as a "project folder", so it seems to be a little awkward to get a state where you have a file but not the folder open. When you remove the project folder after opening a file, the state will not be restored.

Regardless, we need to support hot exit on empty workspaces as only having it work on folder workspaces would seem like another bug and lead to some weird behavior when you close multiple windows at once when some have no folder opened (some will hot exit, some will prompt).

This will be available in tomorrows insider.

@bpasero Is that a newspaper?

You can give our preview releases a try from: http://code.visualstudio.com/Download#insiders

@bpasero I was just kidding. The last 2 words sound like a newspaper name. Sorry! Should have added a smilie.

:]

@bpasero Should the old setting be honored if it is set? I have "window.reopenFolders": "all" and just 'lost' all windows through a restart which used to preserve them.

@chrmarti great catch, I had a bug in my migration code 👍

Hi @bpasero. Just double checking, in the insiders preview looks like the new option is window.restoreWindows right? As I understand it, the value mentioned by @BobbyBabes (last) is probably the new default (now called one) right?

Looks like it is working fine. My only problem with the current version - and I'm not sure if it this is directly related - is that VS Code behavior feels odd when I have unsaved files and open a new folder.

Currently VS Code displays a prompt asking if I want to save new files. If I don't do it the files are gone forever. This happens even with "files.hotExit": "onExitAndWindowClose".

I would expect unsaved files to be "carried forward" and simply be there after I open a new folder.

If I switch between two folders or if I close a folder and open it again everything works as expected (i.e., previous unsaved files are kept - unsaved files are "bound" to the current folder). The problem only manifests itself when no folder is currently open in the editor.

Another problem is that I'm not getting the expected behavior with:

{
    "window.restoreWindows": "all",
    "files.hotExit": "onExitAndWindowClose"
}

Assume that I have two windows open, each pointing to a different folder. If I right click Visual Studio Code Icon and select "Close all windows".

I would expect both windows to be restored the next time I launch vscode, instead I'm getting either an empty window or only one of the two previously open windows.

@aaccioly can you file this as separate issue, it seems unrelated.

Hi @bpasero, ok, will do.

I would argue that "Close All Windows" should not restore the windows because you are actually closing all of them. In the same way if you close a single window we would never restore it.

If you use File > Exit the windows will restore properly and that is the intent of the window.reopenWindows setting.

@bpasero Just wanted to thank you for adding this feature, it was one of my biggest gripes with VS Code before since I work with multiple windows some of which has files from different locations. Hunting them down and re-opening them every time VS Code restarts was a pain!

^^
This!

@bpasero This is more of a question than an issue.

Situation:

Version 1.14.2
Commit cb82febafda0c8c199b9201ad274e25d9a76874e
Date 2017-07-19T23:26:08.116Z
Shell 1.6.6
Renderer 56.0.2924.87
Node 7.4.0

"uname --all" output:
Linux designbox 4.11.9-1-ARCH #1 SMP PREEMPT Wed Jul 5 18:23:08 CEST 2017 x86_64 GNU/Linux`

Preferences: `"window.restoreWindows": "all"`

One VSC window with a project folder opened. All files saved.
One VSC window with just a bunch of files opened. Some with unsaved changes.
Ctrl+Q to close all VSC windows and quit VSC.

Reopening VSC (as per the title of this issue) works as expected. Both windows are restored with all files.
Ctrl+Q again.

Then double-clicking a source file in the file manager, opens one VSC window with just the double-clicked file.
Ctrl+Q again.
Start VSC from its icon, and one window opened with just the one file (that was double-clicked from the file manager).
I restored the initial 2 windows with Ctrl+N, followed by Open recent.

I had expected that starting VSC from its icon, would first open the 2 VSC windows. And that the source file (double clicked from the file manager) would be added to one of the 2 VSC windows. And that that window would be pushed to the foreground.
Similar to what happens when there are already VSC windows opened, and you then double-click a source file from the file manager.

So my question is : is this intentional, and should I therefore open a request for this behaviour to be added ?

Hi everyone, I'm trying to change from Sublime to VS Code so keep the old files is important for me , but I just install the version: 1.15.0-insider, and I'm not able to find the property "window.reopenWindows".
I do have "window.restoreWindows": "all". And of course, is not restoring all the files previously opened.

@bpasero any suggestions? (tks in advance!)

@BobbyBabes yeah that seems like a separate issue to me, you seem to want to restore your context if you start Code via the icon and ignore sessions where you opened code with a specific file. I think it should be reported as such.

Today we simply restore your last session, no matter how you got there (e.g. by clicking the icon or opening a file).

@Curros the setting is now called "window.restoreWindows": "all". If it does not work please report a new issue with steps how to reproduce.

@bpasero Thanks for clearing that up. I'm opening a new request issue right after.

@bpasero

Today we simply restore your last session, no matter how you got there (e.g. by clicking the icon or opening a file).

Are you saying the current intended behavior is to restore all open editors, both clean and dirty, regardless of whether VS Code is launched by the icon or launched by opening a file? Because it seems to me that the "window.restoreWindows": "all" setting is only applying to the former.

No, when you open a file into a window, then we do not restore the other editors.