Restore previously opened folders/workspaces when opening a specific folder/workspace

[rajnisheu]

• VSCode Version: 1.7.2 , portable zip
• OS Version: Windows 10

Steps to Reproduce:

1. Open some workspace folders
2. Close Code
3. Open folder from command prompt by typing code .
4. Last open folders and sessions are lost!

Atom has exactly the same issue :)

[bpasero]

Try with "window.reopenFolders": "all"

[rajnisheu]

Did that already.. first thing when I got started with it.

[bpasero]

@rajnisheu so you say it does not work with that setting?

[rajnisheu]

Yes @bpasero

[bpasero]

@rajnisheu I see what is going on. When you instruct Code to explicitly open on a resource (file or folder), we do not restore the windows. So this setting only has an impact when you just launch Code without providing a path.

[rajnisheu]

I am not sure I can make sense of that @bpasero. To me its not at all intuitive to loose my working session.

Its not unusual to right click and use "open file with" command. If Code wasn't open at that time, all working folders and open files are lost.

This is offered by several tools, including likes of Notepad++ which remember sessions.

I would not call it a feature request. Its fundamental functionality. If it is, its probably unusable by me till we can have that in. Its no fun loosing working folders and files.

Thanks for looking into it.

[bpasero]

@rajnisheu what do we do about people that expect "code ." to open exactly one folder which is the folder the "." is pointing to? A change like this always means to potentially break expected behaviour for some users. Since the current behaviour is intended, I set this to be a feature request because this is not something that happens by accident.

[rajnisheu]

@bpasero I am not able to comprehend why would someone expect "code ." to forget their session where an explicit setting for "window.reopenFolders": "all" has been set. Is that not what the setting "all", "one" and "none" are about?

For lack of a better example, lets take the case of a browser. If its been set to reopen tabs from last session aka remember last session, and after close, if an html file, say from the desktop, is opened, should the browser loose all tabs?

That would be a disaster for a user.

[bpasero]

@rajnisheu how about you double click on a file in the windows explorer to do some quick edits, would you expect all windows to reopen in that case from your previous session? to take it one step further, what about using VS Code as external editor, e.g. to quickly edit a git commit message, would you still expect all windows to open?

[rajnisheu]

You do make a point @bpasero.

But that's not how I see developers working with editors. Editors are open most times. Its those occasional moments when, for example, Windows comes of a reboot (which it does nearly every week ;) ), and you unwittingly double click a file before making sure that Code is open, that loosing session is disastrous.

If its a quick edit of a Git message, it would most likely be for a project. Editing a message.. and loosing the session! I can tell you working with a reasonable size team, single message edits are always in Git tool directly or even command line.

I can't imagine working with a modern tool where I am likely to loose my project setups, tasks and several open (and sometimes unsaved) files, even accidentally. In the end, if I have set session to be remembered, that's what I would expect. Extra seconds spent for loading is any day far more acceptable than loosing work!

Thanks for the clarification though, you can close this thread if you wish.

[bpasero]

@rajnisheu I took extreme examples, but that is the reason why "code ." behaves like it does today. You are basically instructing VS Code to open the current working directory as folder (because you add the "." to it) in a new window. We distinguish such a way of opening VS Code from just typing "code" where we assume you want to restore your previous session.

Now, wether this behaviour is good or bad is up for discussion and that is why I will leave this issue open and flag it as feature request. I am not saying that our behaviour is good or bad, just saying that it is a result of us interpreting "code ." not as an instruction to restore the full previous session but rather to only open the current folder.

[rajnisheu]

@bpasero its the same behaviour with Code installed and doing a right click "open with" instead of using "code .". Doesn't matter if its right click to open folder or file.

Previous session is lost.

Is that really the expected behaviour?

[bpasero]

Yes, as long as Code is opened on a specific path (either file or folder), we use that as the session over any previous session. At least that is a consistent behavior I would say.

[37Stars]

I agree with rajnisheu. Anytime I reopen Code it should automatically reopen all the files I had open previously. If I double click or use the context menu to open a file, it should also show all the previously opened files in their respective tabs, along with the file I wanted opened. The editor doesn't have to actually load those other files until the user clicks the appropriate tab.

Personally, I never have files open from just a single folder. Multiple files are open from multiple folders across multiple drives.

Notepad++ does it right. I can even use a tab in Notepad++ as a temporary copy/paste buffer. I never have to save the file.

At the VERY least you should make it a setting so those who want Code to work the way Notepad++ does, they have that option.

Great editor. Love the plugins, Love the themes. It won't replace my current editor if it doesn't automatically open all of my last file. This is especially true since Windows 10 WILL reboot after an update if even you have the settings otherwise. That's a different issue altogether.

[rajnisheu]

Thanks @37Stars, several users I know and I abandoned Code and decided to stick to Notepad++ / other IDEs. The other extremely helpful feature in Notepad++ is the ability to save sessions. This means if I have two (or even more) multi tab instances of NP++ open, I can save these and come back to exactly what I was doing including unsaved tabs after the notorious WIN10 update. NP++ does get it right!

[bpasero]

What you want is #207 and not this issue.

[jimjoh]

@bpasero

Current thinking is to introduce a new setting window.startup for this because imho we cannot break existing behaviour:

I think your ideas sound good, but I agree with @lautjy that users will continue to be confused by the existing behavior which I consider broken. Why can't you "break existing behaviour"? Defaults can be changed to be better.

[bpasero]

@jimjoh I think it can cause frustration too if this was the default. For example, you may decide to use VSCode as editor for git commit messages and anytime VSCode opens to show the git editor, suddenly all other windows and editors would restore if it was not running before.

I agree that a nice feature would be to be able to restore windows + editors from previous sessions as a way to get back to the last state even when meanwhile a single editor was opened.

Btw I just checked how browsers do it, and Chrome for example does not seem to put "Continue where you left off" as a default:

[sparr]

Your analogy to browsers is not entirely appropriate. Unless you use extensions to do so, browsers don't save user-entered information when they are shut down (like form fields), so less total and less important information can be lost if a session is lost. Further and far more importantly, browsers have different behavior when they crash, and I think it's getting lost a bit in this conversation that part of this bug is the loss of unsaved data when vscode crashes. If you want to analogize to browsers, you need to provide a different workflow with a prompt to the user to restore their session if the program closed unexpectedly.

I still can't believe we need to argue this. Literally every program/platform/app that I use to enter text can restore my "unsaved" data after the program or computer crashes. Sublime, Atom, VSCode, MS Office, Libreoffice, Google Docs, Evernote... This is a standard feature in even remotely capable text editors for the last ten years. VSCode is the only one that throws this feature away because the user happens to relaunch the program in a specific entirely usual way.

[bpasero]

@sparr I cannot follow your argument. Are you implying that VSCode is loosing unsaved data in any way?

[sparr]

Yes. When VSCode throws away the saved session because you opened a specific target file or folder, that session can include unsaved files/buffers.

Search up-thread for "unsaved" or "buffer" for other people pointing out this failure mode.

Reproduction steps:

1. code
2. File > New
3. type foo into the new file
4. killall electron (obviously do something safer and more specific if you use other electron apps)
5. code /

At this point your "foo" seems to be irretrievably lost. If your step 1 had targeted a specific directory like code /usr/src then you could recover the lost file by doing code /usr/src again, but only if you remember that that's the directory you used to open the instance of code where the lost file was.

[bpasero]

@sparr understood, I forgot about a change we did in March: #92467 (cc @aeschli) where we no longer open folders/workspaces that contain dirty files. Fact is, we lost this behaviour for a couple of months and then decided to not bring it back because it resulted in a sudden spawn of tons of windows for users that accumulated dirty files in various folders and workspaces. Our UI solution was then to indicate workspaces with dirty files in the picker with a black dot:

Still, this is NOT data loss. You will always see your recent workspaces in VSCode to navigate to and whenever you navigate back in you will get your dirty files back.

To summarise:

• we used to restore every folder, workspace, empty window that contained dirty files until 1.32 where we lost support for this for folders and workspaces
• in 1.43 we decided to keep this behaviour (empty windows with dirty files still restore because there is no other way of getting your data back)
• we never supported to restore folders, workspaces, empty windows when you ask VSCode to open a specific file or folder (basically what this issue is about)

I feel the original intent of this issue was to restore the windows and editors independent from having files dirty or not. Arguably we could introduce a setting that would only restore those windows with dirty files, but I feel that is not really what people asked for here.

Does that make sense?

[rajnisheu]

@bpasero I am the original poster of the issue, and am glad this is being visited four years on! Better late than.. :)

What you say in #15949 (comment) is exactly what I think the behaviour should be.

Most people understand the implication of opting for "Continue where you left off". And that is what VSCode should do. As with the browser, or infact similar tools, if there were 15 windows open, all should restore. If VSCode can handle opening an isolated instance for git diff or git commit, good. But not at the cost of loosing work. In any case there are other possibilities to handle diff or commit as well.

With this feature, and multiline tabs, VSCode will achieve awesome 🥇 and can become a truly mainstream IDE 👍

[sparr]

@bpasero I do not understand how to apply your description to the reproduction steps I provided above. How can I recover my unsaved "foo" file?

[bpasero]

@sparr that depends wether the untitled file is part of a folder/workspace context or an empty window:

• empty window: we always restore that window and file
• folder/workspace: you get the dirty file back once you opened that same folder or workspace (you can use File > Open Recent > More... picker to see all folders/workspaces that have dirty files)

[sparr]

That's amazingly useful and not at all intuitive. Thanks to this advice I've been able to recover three dirty workspaces with unsaved files that I thought were lost.

Sadly the one I most regret losing, the one that brought this bug to my attention, is not represented in that picker. I only wish I'd known to check there when it happened.

[StephanRoemer]

• default: behaviour as today, selecting a file or folder to open when VSCode is not running will only open that
• restore: depending on the window.restoreWindows setting, all windows from the previous session will restore first and then the file or folder will be opened. if a file is selected, it will open in the same way as if you had VSCode already running and open it then (i.e. in the last active window or the one that has the folder opened the file is in) and if you pick a folder, it will open a new window or reuse the last active one depending on other settings

Thoughts?

This is totally how I would expect it to work, huge 👍 !

[bpasero]

I presented this in our UX meeting and think we can push this to insiders for feedback. One discussion was around the name of the setting. The existing proposal was to have a new setting that controls this behaviour, however it might be very confusing given we have window.restoreWindows already.

How would people feel if we added another option to window.restoreWindows to control this? This would mean, you could not chose anything but to restore all windows, but I feel that is the gist of this issue anyway. The sum of options in window.restoreWindows would then be:

• preserve (new): all windows are restored, independent of how VSCode was started
• all: all windows are restored, but not when you start VSCode on a file or folder
• folders: only folders are restored, but not when you start VSCode on a file or folder
• one: only a single window is restored, but not when you start VSCode on a file or folder
• none: no window is ever restored

Thoughts?

[StephanRoemer]

Sounds good to me!

[bpasero]

I have pushed window.restoreWindows: preserve as new choice. all is still the default. We might want to revisit the name of the setting value if we find a more suitable one. This can be tested from tomorrows insider build and then I would appreciate if people could report back how it goes.

One potential feature request I already see is to support --new-window command line flag to enforce opening a single file into a new window even when window.restoreWindows is set to preserve. Currently a file will always open in one of the windows that restore.

[lautjy]

Ah, --new-window would definitely be helpful 👍
Hard to find which window has opened a file I clicked (hence I use other editors for single files these days).

[jonatino]

I have pushed window.restoreWindows: preserve as new choice. all is still the default. We might want to revisit the name of the setting value if we find a more suitable one. This can be tested from tomorrows insider build and then I would appreciate if people could report back how it goes.

One potential feature request I already see is to support --new-window command line flag to enforce opening a single file into a new window even when window.restoreWindows is set to preserve. Currently a file will always open in one of the windows that restore.

@bpasero what determines what window the file opens in?

[sparr]

In a perfect world, it would open in the same place that it would have opened if you'd already had vscode running and opened the file from outside the program, which I think depends on whether or not the file is within any existing open workspace.

[bpasero]

@jonatino yes I think @sparr described it well. The experience of opening a file will be the same independent wether VSCode is running or not. We have some logic that tries to find the best window when opening a file. E.g. ensuring that a file opens in the window where the parent folder is opened in.

[bpasero]

This can now be tested from our insiders release channel: https://code.visualstudio.com/insiders/