Add support for opening multiple project folders in same window

[stoffeastrom]

Right now it doesn't seem possible to opening multiple project folders in the same window which imho is a bit constraining. If you are working on modular modern projects it's a must have to be productive.

[dgileadi]

If the "one section per root folder" solution is chosen then I'd like to suggest that the currently visible root folder "sticks" to the top of the sidebar, instead of scrolling up out of view. It would only scroll up once the subsequent root folder reached the top of the sidebar.

On Jun 4, 2017, at 6:47 AM, Peter Petrov notifications@github.com wrote:

I prefer the "one section per root folder" design, for the same reasons listed by @maddouri. In addition, having used the other alternative (in Atom), it's visually harder to find where a new root-folder starts when multiple highly-hierarchical folders are open and expanded.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[svipas]

Or we can follow Sublime, Atom approach, but change color or somehow show which folder is the root and/or stick it to the top. Of course both approaches are good, but having a lot of opened folders reduces space, because bar with refresh, create a new file, etc. will be visible, that's why it's better to don't load bar, but somehow show which folder is the root. BUT again, this bar is really good, because it's much easier to see opened root folders and you can refresh them and do other things which are included in the bar. We need to see how it looks like with for e.g. 10 folders opened with and without bar.

[stefcameron]

@stevencl Thank you for posting those recordings! Overall, I'm excited about the direction in which the feature is heading! Thank you for all the time and effort put into it so far. Here is my feedback/thoughts:

• I prefer the first design with the single folder name bar design under "EXPLORER", however, I'm concerned that if all folder names are listed there, it'll very quickly get truncated in order to show the "add file", "add folder", etc., buttons. I think I'd just put the string "Multiple" or something similar when more than one folder is open; otherwise, there's just one folder so put the name of the folder there as is done today (and hide the folder root in the tree).
• The disambiguation of file names by appending the folder name in the tab title in the Editor, IMO, is not necessary unless there are multiple editors open with the same file name. Note that this scenario is not uncommon even with a single folder open. It's quite easy to get multiple files (e.g. .gitignore) with the same name among subfolders within the same root. So this design (appending the parent folder name) should be a separate feature, IMO, and should be implemented. Along with this, I'd love to see a good solution to https://github.com/Microsoft/vscode/issues/15048 because this will make some tab titles even longer. :)
• For search results, I think it's essential that search work across all root folders. Another filter could be added to limit the search to chosen roots. When displaying results, it might be useful to see results per root, so maybe an option to see one long list with root folder names appended, or to see a list separated in sections, one for each root folder.
• I find it strange that you're proposing to add 'workspaces' to the user settings. I really expected this to end-up in workspace settings. I think you're actually saying that the workspace settings can also contain the new 'workspaces' property, which is good. It's also really good that workspace paths can be relative. It just doesn't seem to be something that belongs at all in the user settings. It's a feature that feels very specific to workspaces. Ah, but now I see why it's also valid in user settings, because it affords me a way to store these workspaces when I want "random" folders on my HDD in one workspace where there's no common root.
• One thing that seems to get lost in the workspaces when they're stored in user settings is the ability to have other project-specific settings attributed to one workspace or another. For example, if I had a workspace where I needed the tab size to be 2 spaces and another where it had to be 3, I wouldn't be able to do that with workspaces in user settings. I'd have to create a folder somewhere, and then put a .vscode folder inside of it, and then define .vscode/settings.json in order to finally define my workspace with the appropriate tab size override. At this point, I'm thinking that creating a new VSCode Project file type that stores all these settings and can be opened as a special file becomes much less cumbersome than having to create this hierarchy of folders to store the workspace settings.json file...

[gulshan]

In first design, for additional folders, the path (relative or absolute) in parenthesis can be appended to the name for differentiation. That will be a simple solution I think.

[alefragnani]

@stevencl thanks for recording the sessions. I really wanted to participate but wasn't available at the time 😢

I liked the proposed SCM interface. Having a summary section and the One section per folder gives me, IMHO, a much easier interface to detect and work with the changes. And I like the idea to have a consistent behavior in the entire UI, so the One section per folder idea should be used in Search tab as well, instead of concatenate the folder name at each result. The same for the Explorer tab.

Using the User Settings to store the Multi-Folder is a bit strange for me, because it doesn't seems to be a user setting :smile:. If the intention is to avoid creating new files and making it easier to transfer/sync projects/workspaces between computers, why don't you just forget about the user settings and make the additionalFolder entry always part of the Workspace Settings. Doing so, when you Add a Folder, it will be added only to the Workspace Settings. Then, when opening a folder, you just look for .vscode\settings.json file and a additionalFolders entry in there, to check if this is a multi-folder workspace. It's similar to the second example that you used, about the two missing git repos.

SomeFolder.vscode\settings.json

{
    "editor.wordWrap": "off",
    "editor.codeLens": false,
    "editor.renderWhitespace": "all",
    "workbench.colorTheme": "Abyss",

    "additionalFolders": [
        "./express",
        "./express-plugin",
        "~/commons/other-stuff",
        "file:///C://Temp//oldlib"
    ]
}

Also, support user-data locations like ~ and $home, making easier to share projects between different computers/platforms.

I missed only one point: API. How extensions would integrate with that?

Thanks for the efforts. Looking forward for the first insiders releases 👍

[bpasero]

Thanks for the feedback! I wanted to follow up on the direction of leveraging a new settings property additionalFolders to implement "Multi Root" because I hear some feedback on this from the comments above.

The main motivation for introducing a setting in the first place is actually to keep things simple and not introduce too many new concepts while still having a solution that is powerful and enables some interesting scenarios. Here are some design decisions and consequences:

Keep it simple We feel that opening files and folders is at the core of VS Code. Thus we would not want to introduce a new top level concept of "Projects". For example, we would not think a "Open Project" action was needed, but rather think that a project is always a folder and it can optionally have additional folders associated. With this assumption, a setting seems like the natural way of allowing for that. Whenever you open this folder, you open the additional folders with it. Adding and removing folders is a simple gesture and it will update settings directly.

Settings are powerful Having multi root as a setting enables a lot of interesting scenarios. For example, you are free to put the additionalFolders setting into your workspace and as such share this with other people (by using relative paths - this is shown in the videos). On top of that, you are also free how you setup projects in the first place: for example, in some cases there is no clear relationship of a master folder to additional folders (e.g. it could be that some of them are not even related to each other). In that case you could just create a "project" folder that just includes a settings.json with the folders it links to:

allMyRandomProjects/ 
  .vscode
    settings.json <- contains additionalFolders setting  

Now when you open allMyRandomProjects it will show you the list of folders based on the settings. You can even include some settings in settings.json that should apply to all the folders shown.

Workspace switching and multi windows Without a doubt, we need to work on better workspace switching and multi windows support in VS Code. Since we treat a multi-root workspace the same as any other workspace with a folder, improving workspace switching and multi windows support will benefit any user, even those that are not leveraging multi-root workspaces. We will have to look into better and easier ways of switching between folders and opened windows independent from multi-root.

In my next comment I will provide some feedback on individual comments made.

[bpasero]

@borekb search would include options to limit to a specific root folder (or multiple) in the same way you can configure search to include a specific path today already.

@maddouri @TurkeyMan @pesho, @dgileadi @stefcameron it seem clear that some people prefer a single tree and other prefer multiple sections in the explorer. So we might end up with a setting for this, there are pros and cons for both solutions and it should be up to the user which one is better for the scenario.

@borekb how settings apply will change a little bit depending on wether you are in a multi-root setup or not: user settings always apply to all folders opened as before. Workspace settings will be picked up from the main ("master") folder and applied to all files and folders that are associated to it. Now, you can still define settings on any of the additional folders via workspace settings though we might not support all of them. For example a setting like update.channel: none cannot be supported on a per-folder basis. What we will have to do is to identify settings that we can support on a folder level (e.g. files.exclude, all editor settings) and make the necessary changes to enable them. This is one of the major areas of work we have to invest in, especially since extensions can also define settings that we want to support on a per-folder scope.

@BTMorton it seems to me you want easier ways to switch workspaces. This is something we should look into independent from multi-root for any folder transition a user can do.

@stefcameron we will keep the additionalFolders setting open enough to eventually add additional meta data to it. For example I could think of being able to provide a name for such a config so that switching between projects goes by name and not main folder.

[bpasero]

One thing that we have not touched on yet in the videos is how extensions can support multi-root folders. Another primary goal with multi-root support (besides "keep it simple") is: do not break extensions

Today, extensions have simple API to get access to the currently opened workspace (workspace.rootPath: string). This property can be null in case no folder is opened.

Now, with the introduction of additionalFolders setting, an extension can still rely on the workspace.rootPath property being set (if a folder is opened), or not (when no folder is opened). Since additionalFolders is actually a setting, an extension is free to read and even write to this setting with the APIs we have today around settings already. There is even an event emitted when this setting changes, allowing for dynamic reaction to the user changing this setting.

Reading this setting allows to make an extension aware of additional folders in the workspace. E.g. the Travis CI extension could chose to show an aggregated status across all folders.

Writing this setting enables some interesting scenarios for extensions: e.g. you could have a project-manager extension that dynamically adds and removes folders to your workspace and as such allows for project transitions within the window, e.g. by showing a list of projects via a picker UI.

At one point we will probably introduce some real new extension API to deal with multi-root folders. Burying this inside a setting for extensions to read/write is a bit odd. But to begin with, extensions can already explore the additionalFolders setting to leverage it if possible. We will also work closely with extension authors to understand their scenarios and how to better support them.

[felixfbecker]

@bpasero Will the concept of additional folders also be added to LSP, or will VS Code simply start one language server per additional folder?

[bpasero]

@felixfbecker this is something we still have to invest and explore to find a good solution for language extensions. Once we think about additional APIs for extensions we also need to think about what this means for the LSP.

It is worth mentioning though that today you can already have situations where users open a file from a folder that is not opened as workspace (e.g. File > Open > somefile.xyz). Ideally a language extension can show the same level of language features for such a file even if the folder of that file is not opened.

In the beginning, opening a file from one of the additionalFolders would behave very similar to opening a file that is not in the folder you have opened initially. TypeScript for example can deal well with this case: they just walk up from the currently opened file until a tsconfig.json file is found and then treat this as a project. Features like find references work without issues:

It would be nice if any language extension could work by just going from the currently active file instead of forcing to have an explicit project context.

[borekb]

@bpasero thanks for the comments. So it seems that in the current model, there will always be a "master" folder: even in the allMyRandomProjects example, this is basically the master folder, though mostly empty. This has some subtle implications but I'd need to think about it some more to provide useful feedback.

Overall, I think that VSCode should support monorepo vs. multiple repositories in a pretty similar way, as per the comment above: https://github.com/Microsoft/vscode/issues/396#issuecomment-306040485.

BTW, how do you define "root", exactly? If I open folder A that contains subfolders B and C, how much is it different from defining A as path and B and C as additionalFolders? Is the intention for VSCode to treat those two situations fairly differently or basically the same? (I think it should be be very similar experience.)

[felixfbecker]

@bpasero

In the beginning, opening a file from one of the additionalFolders would behave very similar to opening a file that is not in the folder you have opened initially. TypeScript for example can deal well with this case: they just walk up from the currently opened file until a tsconfig.json file is found and then treat this as a project. Features like find references work without issues:

TypeScript does not use LSP though. In LSP, language servers have a rootUri, and for example PHP will use this rootUri to scan for files that need to be indexed. It doesn't have a file like tsconfig.json that would denote a "project". So if there are files that are not opened through didOpen but also not under rootUri, then these would not get considered for code intelligence, hence my question whether LSP will get extended for this.

[saborrie]

Just to clarify, would opening multiple roots create a file ./.vscode/settings.json if it didn't already exist? As from what I've read here so far it looks like we're saying it would.

I understand why its useful to avoid adding the concept of projects, but perhaps it would be good to make the saving of a workspace optional - even though in this case, 'saving' just means creating a settings file in the root folder.

I think it might surprise a user who hasn't been following this thread if they opened a second folder and it created a settings file. Opening folders is the kind of thing I believe most users expect to be read-only.

[stevencl]

Thanks for all the feedback everybody, this is very useful.

@saborrie - good question about the extent to which people would be surprised by the creation of a setting upon adding a folder. We will need to investigate that to see if that is the case (obviously with people who have not been following this thread :-) ).

@borekb - we have talked about the scenario you mentioned (opening a folder that contains one or more subfolders) and we have been leaning towards treating this the same as opening a multi root workspace. The challenge though is in determining when to treat such a situation as multi root and not just a folder that contains other folders.

I'd be interested in what others think about this too.

[bpasero]

@borekb you bring up a good point, I would also say that if you open one folder that contains multiple git repositories within, our SCM view should be able to show you the same view as you would get if you set this up explicitly via the additionalFolders property. I think we can start to explore this UI evolution with folders that have additionalFolders setting set and later expand it to more use cases. Another interesting and related scenario is how we chose to present submodules in a repository.

I would also think that eventually we want to support .vscode settings on any folder hierarchy level once we have solved the challenges that come with it.

I would speak less about master-details relationship when talking about multi-root because most of the UX will treat the main folder equal to the additional folders. Master folder is really just the container of the settings for additional folders and will be the main driver for global workspace settings. For backwards compatibility it will also be the one we send to extensions as rootPath.

@felixfbecker does that mean I cannot do a "Find References" or similar language features when opening just one PHP file of my project, I need to open that folder to get these features? I am not deep into PHP, but if there is a concept of cross-file dependencies, I would not be able to navigate to another PHP file from just a single file, I need to open the folder first?

@saborrie we would NOT add a workspace setting by default when you add folders. One of the reasons we decide to put this into user settings is so that a workspace is not becoming "dirty" with the multi-root setup. Putting this setting into the workspace is possible, but you will need to do so manually. It will not happen by default.

[saborrie]

@bpasero Ok yes, sticking with the saving into user settings rather than workspace settings would prevent the dirtying of the workspace folders - I'm guessing that it would still save before requiring the user to explicitly perform a save action though yes?

That leaves me with two follow up questions:

1) What would happen when a user opens a workspace with additionalFolders defined in its workspace-settings? Would this become synced into their user-settings? and would it override the entry for that workspace-root if it existed in the user-settings workspace list? Or vice versa?

2) Is putting this list of workspaces into user-settings a better option than initially avoiding storing workspaces in either of these JSON settings files? In the current single-folder system, when a folder is re-opened from the File > Open Recent menu item, the tabs which were open previously are remembered - as far as I can tell this isn't being stored in any user-editable settings file, couldn't the additional paths be stored in the same way, until a user saves them explicitly?

[Tekbr]

-- Sorry for the English, I used Google Translator --

Well, I went over the layout, (yes - a little difficulty in understanding English). Sorry then...

I did not like the layout presented by @maddouri, mainly due to the problems found in this issue (#25352, #25354). I think it will be more complex even if you have to use the keyboard to access the folders in the displayed model.

I prefer this model, which by the idea I can navigate between the different project folders using the arrow keys and if I need to create a folder / file in the main folder, I can use the menu key on the keyboard, right in the main folder.

And / or with the options of new file, new folder update and Collapse All.

As for the title that appears at the top, I prefer that it focuses on the current file with the folder it is in, or instead of showing all open main folders plus the current file, similar to this image.

And a question: Will Open Editores still exist?

[felixfbecker]

@bpasero

does that mean I cannot do a "Find References" or similar language features when opening just one PHP file of my project, I need to open that folder to get these features? I am not deep into PHP, but if there is a concept of cross-file dependencies, I would not be able to navigate to another PHP file from just a single file, I need to open the folder first?

That is correct, if you just open a single file, you cannot go-to-definition to a file in a different file that is not open, but only to those below the rootUri. That is because in PHP every file can dump symbols in the global namespace, and namespaces are really just name prefixes for classes. There is no restriction on how namespaces and class names need to correspond to directories and file names (only some conventions), and there are no import statements like in TS, only namespace aliases. Loading classes happens at runtime through registered "autoloaders". That means for a language server on go-to-definition, a symbol could be defined in any file. So the language server will index all files in rootUri on startup and then work with the index to answer requests. What does work is if you have a project open, and you create a new unsaved file - you will get intelligence for that, because you got the rootUri and the new file through textDocument/didOpen. But any symbols defined in not-opened files not under rootUri will not be considered.

[bpasero]

@saborrie workspace settings override user settings, same as before. A additionalFolders setting inside the workspace always takes precedence. Given the nature of this setting though, you can only override the additionalFolders for the currently opened folder when this setting is specified inside the workspace (this is shown in the videos by having path: "." for the "master").

Having this as UI state stored similarly to e.g. how many tabs are opened was an option that we discussed but we did not find it has lots of advantages over a setting. Some reasons:

• this is not shareable (neither via workspace setting, nor via a settings sync extension)
• this is not something extensions can access today easily (settings API exists, UI state API does not)

Is there a particular reason you would not want this inside settings?

@Tekbr yes, "Open Editors" will work as before

@felixfbecker would the PHP extension able to adopt something like rootUri: string[] easily? Or would you rather want the PHP language server to get started multiple times for each folder opened (e.g. VS Code would multi-plex on the level of opened folders to N language servers?)

[felixfbecker]

@bpasero PHP could work with rootUris: string[] quite easily. Other language servers may not though. Spawning multiple language servers would mean each folder works isolated (no jump-to-definition, find-all-references between them). Maybe an approach would be a new ServerCapability that decides whether VS Code will spawn one or multiple language servers.

[bmewburn]

I like the concept of the additional folders setting. For me having a single root folder is enough. If I want full development functionality on an associated project I can open a new vscode window.

What I need from the additional folders is just limited functionality. For example I might want a symbol definition from an associated project for use in the root project but not need or want the ability to rename it or find all references for it in the additional folder.

[saborrie]

@bpasero I'm just advocating for considering making the creation of a workspace in settings optional (and opt-in). Essentially instead of automatically changing settings when a user adds a folder, start with it just in UI state, and then allowing users to save this to settings in some way. Perhaps also allowing a choice of whether it goes into workspace settings or into user settings.

I'm not completely against storing entirely in settings, I'm just doing my bit to question the decision not to use UI state, just in case it had been overlooked.

[stefcameron]

@bpasero @saborrie If we go that route, then I would add that when prompted to save to settings, there should be an option to "remember my choice" (to save workspaces to settings, either user settings or project settings). I would be disappointed to open a VSCode window, load a few folders, get it all working the way I want and then either a reboot or crash occurs and I've lost my whole configuration for that combination of folders because the workspace was never saved to disk.

[Tekbr]

#396 (comment)

@Tekbr yes, "Open Editors" will work as before

Thanks for the reply, @bpasero.

[iam3yal]

TL;DR: Use a tree view whenever it make sense as opposed to appending the name of the roots to each item.

Few things, I really dislike the way you append the folder to the end, I'd really like it to be an option because I would probably like to have it like thisexpress\.editorconfig and express-plugin\.editorconfig so maybe you can offer the following option: editor.tabName: "${root}\${filename}"

Another thing I would like and you mention it in the video is coloration over roots to match the tabs so 👍 for this.

Search:

In the Search view I'd actually think that you're making a mistake as far as the experience goes, in my mind it should be displayed as a tree, like this:

[-] express
    [v] file1.ext
         ... expression ... 
    [v] file2.ext
         ... expression ... 
[-] express-plugin
    [v] file1.ext
         ... expression ... 
    [v] file2.ext
         ... expression ... 

The reasons for this is:

1. You can easily see where are the files regardless to the length of their names.

2. You can collapse the roots you don't want to see.

I think that it also fits more to the kind of design you applied to the Explorer.

Tasks:

For Tasks I'd prefer to have this kind of view:

express
    Compile
    Run Tests
express-plugin
    Compile
    Run Tests

Few points:

1. In my opinion you shouldn't touch/change the folder names, meaning "express-plugin" should be displayed exactly as it's displayed in the Explorer and not as "Express Plugin".

2. Moving between tasks with the keyboard can also be made in such a way that it ignores selecting the roots so if you move down from express\"Run Tests" in the example the next item that would get selected is express-plugin\Compile as opposed to express-plugin

p.s. Haven't seen the whole video yet but these just things that came to mind.

[doublehelix]

What if all of the root folders you include in your workspace have the same name? e.g.

• /dev/project/public/src
• /dev/framework/src
• /dev/some-component/src

You would then have a workspace with:

[+] src\
[+] src\
[+] src\

As per the sublime way of including folders in a workspace, each virtual folder root has:

• Path
• Name (optional) - this is the name of the folder if excluded, but can be displayed as anything
• Exclusion filter for Files/Folders

See note https://github.com/Microsoft/vscode/issues/396#issuecomment-283541760 (above) for example of the metadata associated with this way of doing things.

[ifzm]

I would like to know that this feature is still in the development stage ?

[iam3yal]

@ifzm It is and if you read the latest (May 2017 (version 1.13)) release notes you would know that they are actively working on it.

[ifzm]

@eyalsk Sorry, I did not look carefully, this is an exciting feature :D

[glen-84]

I'm not crazy about the additionalFolders concept, although I understand the desire to keep things simple.

It seems strange to me that one of a set of folders will store the configuration of the "workspace".

Imagine the following root folders:

• website
• api
• mobile

... which folder should hold the additionalFolders setting? Why?

I prefer the idea of a workspace/project manager, where the settings are stored in a shared/general location. I really don't think that this is complicated from a UX perspective, and the existing workspace terminology could be reused/extended.

---

Unrelated: I fully agree with @eyalsk's comments regarding nested lists (and tab naming).

[bpasero]

@glen-84 in that case you are free to have a fourth folder on disk called "my-mobile-website-project" which has this setting and links to all the other folders.

[glen-84]

@bpasero I understand that, but it's really just a hack.

[glen-84]

To elaborate:

I'm busy working on the website, and decide that I want to make some changes to the api. If I click Add Folder, it's going to associate the api with the website, such that opening the website in future opens the api as well. I need to understand how this works, and when I do, I have to open a separate instance of VSC, create an appropriately-named empty folder, add both "project" folders to it, and then close off the initial instance.

In contrast, I could simply go Add Folder, and it could (optionally) prompt me for a workspace name to use in future for opening both folders at the same time.

workspaces.json (example)

{
    "workspaces": {
        "My company workspace": {
            "folders": {
                "/path/to/website": {
                    "folder-setting1": "value1"
                },
                "/path/to/api": {
                    "folder-setting1": "value1"
                }
            },
            "settings": {
                "workspace-setting1": 123
            }
        }
    }
}

I just feels more flexible and less awkward to me.

[bpasero]

@glen-84 understood. going with your proposed solution makes using VS Code more complex, that is why we chose against such a concept. The main reason is that suddenly there is not only "Open File" and "Open Folder" but also "Open Project". Staying with the primitives we have is the more straightforward approach without introducing new concepts.

That said, all the work we do now to support multiple folders is good work also for scenarios as the one you propose. If we ever want to support your scenario, the steps to get there are much less heavy because the UI is already fit for it. I could also envision that maybe an extension could introduce such a notion of workspaces and we just add the necessary APIs to support this.

Let us first get the UX right without introducing new concepts and then think about other scenarios around multi-folders. There is lots of things to look at first (extensions, settings, SCM UI, etc.).

[glen-84]

your proposed solution makes using VS Code more complex

I have to disagree with this. If a user is confused by an optional "Open Project" (or workspace) feature, then they're likely to be confused by many existing features in VSCode. This is not complicated from a user perspective (if anyone reading this disagrees, please say so).

I could also envision that maybe an extension could introduce such a notion of workspaces and we just add the necessary APIs to support this.

The extension already exists, and has been mentioned a few times already. The author even has an open ticket tracking multi-folder support. This extension has 370k+ installs, and a rating of 4.7. Even with a simplistic UI utilizing the command palette, there is little sign of confusion judging by the comments.

Let us first get the UX right without introducing new concepts and then think about other scenarios around multi-folders

That's fair enough. Either way, it's about supporting multiple root folders within the same window – the actual method of managing these folder groups could be tackled at a later stage.

Would you consider creating a public poll to gather user opinions on the subject (I'm aware of the YouTube videos, but I'm referring to this aspect on its own), or has the decision already been made to go with the additionalFolders concept?

[pltrant]

I agree with @glen-84. I don't understand the complexity issue. Yes, it can make it more complex, but this is a code editor. I would think it's 95% of programmers who are using it, which could easily understand the idea of projects. There should be little concern about confusing every day people because every day people aren't using it.

While an extension is somewhat of a solution, extensions are also second rate compared to being natively implemented enhancements (i.e. can't add options to the menus, only the command pallette, etc).

[bpasero]

@glen-84 the decision has been made to go with additionalFolders setting based on sentiment in the development team, user studies we did (those 2 videos) and feedback we got in this issue.

@pltrant it makes using multi root more complex because you constantly have to think about opening a folder or opening a project. Things like "Open Recent" would suddenly require more attention if the entry picked is a folder or a project, or worse you would even have 2 pickers and have to decide which one to use.

I am not sure how having a setting is more complex. You basically do not have to care about the setting, you just add and remove folders to your setup and the setting is being updated in the background. I would argue that you never look at the value of that setting in most cases.

[gulshan]

@glen-84 Regarding your example of a project with 3 folders of same importance, I think which one should contain the additionalFolders settings should be decided on dependency. If API folder is not dependent on other project, when it is opened, it should be opened as a single folder and should not contain any additionaFolders settings. But when you open the mobile folder, I guess it has a dependency on API folder. So, you add the settings in mobile folder for opening API as an additional folder when opened in vscode. Same goes for website. If it's dependent on api, add settings there. If not, no settings needed.

I don't think there will be recursive or cascading additional folder opening. I also like the idea of extensions read other project formats like Visual Studio Solutions and suggest/put additionalFolder settings in place. And you can always open the common parent folder of all.

[bkbonner]

@stevencl watched both videos.

1. Alternative 2 with the disambiguation seems the most clear. It seems like this could be collapsible (i.e. one of the roots in the tree) which would allow for many projects to be seen at once. If you need a mockup, let me know.

2. Alternative 2 is more efficient from a screen real estate perspective. You won't have the same info (name of the project) repeated at the top -- as in option 1 and then shown in the root of each project.

3. Search Results and Git could behave the same way...as a collapsible tree. The results would be grouped (along w/ status) under their appropriate heading. I guess if you want a navigable summary (as you showed for GIT, that would be an option that could exist across search (how many files you found) and the project area (this could house the action buttons).

So in summary, I'm a fan of the individual collapsible roots w/ the possible addition of the navigable summary. Sort of a combination of Alternative 2 and this example

I hope that whatever you folks choose, that you make the experience similar across the various mechanisms. You say that there were two alternatives, but there are really 4 since GIT and Search were both different. I"m agreeing with whoever made this comment

Re: sharing of the multi-project info. I think it would be useful -- how you have it would be reasonable as a start -- I'd make it just use gulp tasks -- or tasks that VS Code could understand.

Thanks for all of your effort on this.

[gulshan]

The implementation of multi-root workspace is being tracked at #28344 and in this June milestone.

[glen-84]

@gulshan,

There can be cases where there are no dependencies. For example if I'm working on website and decide to add mobile to work on it at the same time. There are no dependencies between the two, but now website becomes the "parent". If I happened to be working on mobile first, then it would become the parent. It's just a bit arbitrary. The folders could also be for completely unrelated projects.

Regardless, I respect the decision by the VSC developers, even if I don't necessarily agree with it.

[stevencl]

Thanks for all the continued comments. As has been mentioned above, we are tracking the work in issue #28344. We will take into account these comments while we continue to work on this, especially while designing the SCM experience. As was discussed in the videos and as has been mentioned above a number of times, we want to achieve consistency throughout the experience.

Regarding the complexity issue that @glen-84, @pltrant and others have brought up, thanks for the detailed suggestions and responses. We understand the feedback and will continue to monitor this as we work on the feature.

The discussion around this has been really helpful and has given us some things to think about for our current design. For example, perhaps we should consider allowing users to choose the 'primary' folder when they add a second folder to a workspace. Maybe we prompt for this when the workspace is closed, maybe it's a setting. Lots of things for us to think about to streamline the experience.

As @bpasero mentions though, we are always very reluctant to add new concepts (such as projects) to VS Code. It's not because we think it would make VS Code unusable, it's more that additional concepts adds to the weight or heft of VS Code, making it feel more complex. Such concepts would be something else that developers have to devote mental resources to.

Furthermore, once something is in VS Code, it's a lot more difficult to take it out (over time people get used to it and depend on it). So we spend a lot of time carefully considering what we add to VS Code and only add something when we are confident that the cost of adding new concepts will be worthwhile. So right now we want to determine how successful a design for multi root that does not add new concepts can be.

Once again, thanks for the incredibly valuable feedback. Without a dialogue like this it would be a lot harder trying to design this experience.

[borekb]

Awesome how thoughtful and responsive all of you on the team are; it's really appreciated!

What probably hasn't been said yet with regards to complexity is that you are adding some anyway. I think these two options are currently discussed:

1. Explicit projects.
2. Something that looks like plain multiple folders but actually isn't – there's an important concept of a primary folder which concerns things like rootUrl for extensions and possibly other things (workspace settings inheritance, for example). I think that typically, VSCode user will need to understand this concept and maybe it would be easier to be clear and upfront about it rather than trying to abstract it away.

I'd actually prefer the third way, really not introducing anything new, just handling things like multiple .git repos and search and tasks and things like that in a transparent way – sort of what the first two thirds of the videos suggested (I very much liked the wireframes). However, then I realized rootUrl needs to be considered for extensions which is probably the main reason why this is complicated.

If it weren't for rootUrl, I'd just start with UI updates as proposed in the wireframes plus local persistence of multi-root workspace, the same way as all other folders are persisted in "Open Recent".

I'd like to repeat that from my point of view, the ideal state is where VSCode works with multiple folders regardless whether they are SCM roots or not (monorepo vs. multiple repos, see above). I believe that the proposed wireframes plus some extra core work like inheriting .vscode settings would be enough for "v1" of multi-root support. "Projects" or "primary + additional folders" could come later, IMO. However, what I'm saying might fall with rootUrl, I'm not sure about that, I just want to convey my general sentiment about this.

It's great that you're trying to solve this difficult problem and keep the simplicity as much as possible!

[fipda]

I have a backend and frontend node project, and have 2 VisualCode editors open, which is a significant resource strain.

I watched both videos and agree with a comment above that these multiple projects need not have anything to do with oneanother. Perhaps one could be a nodejs project while the other is C++.

I did not like the idea of one of the projects becoming the "master" project, with the additional projects added. Each project should be equal and unrelated.

I would have expected to be able to open a folder, and then open another folder (not ADD). The folder will simply be added as in video 1, with the roots just showing up (but show full paths in a tooltip when hovering the root folder). These projects would be completely unrelated. Selecting either one or the other would cause a context switch. It would be as if I was switching between 2 instances of Visual Code, both settings, color schemes, and what not.

The way to persist these multiple projects would be to save this as a new project file, that references the other two projects, but without modifying any of the 2 projects itself. In other words, the 2 projects remain independent, self sufficient and unaware of the 3rd project (settings file) that references them.

Once this 3rd file is saved/created, it should be possible to create settings that override settings from project A and B. Settings not created will again depend on the active project.

When sharing the project, one can share the project file that references the other two. When they are missing from the file system, but contain a reference to their github urls, it should ask the user if it wants to fetch them (by default as a subfolder in root of that master project file, but user may browse for a desired location for each).

Ability to search across multiple projects should be optional, and ability to run and debug multiple projects simultaneously would be very useful, but seems really too complex for a first release, and perhaps such usecase should require running 2 instances anyway. At least for now.

How this should look in the UI is step two, but functionally this is how I would expect it to work. I do not like the idea of modifying either project A to reference B or vice versa, and that is kind of what I understood was the intention. For Agile developent, I'd be just happy if I could work on 2 projects in 1 window isntead of having to run 2 instances, but no more than that for now. Perhaps not even with the 3rd overriding project file, but only with context switching.

[stevencl]

Thanks for the continued feedback. There is a definite theme about delaying the persistence of a multi folder workspace until some explicit action from the user (such as save). We'll need to think more about this and investigate further.

[danielsokolowski]

I would also suggest the developers take a look at Eclipse IDE on how it handles this functionality, they figured it out long ago and it works great.

On Tue, Jun 13, 2017 at 9:11 AM, Steven Clarke notifications@github.com wrote:

Thanks for the continued feedback. There is a definite theme about delaying the persistence of a multi folder workspace until some explicit action from the user (such as save). We'll need to think more about this and investigate further.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode/issues/396#issuecomment-308110390, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQsBWywBoe2KQRGuXKHv179MmugstCfks5sDop7gaJpZM4Gm3nX .

-- Daniel Sokolowski Technical Architect

Stantive Technologies Group Inc. Phone: +1 (613) 634-7410 http://www.stantive.com

Notice of Confidentiality: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review re-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error please contact the sender immediately by return electronic transmission and then immediately delete this transmission including all attachments without copying distributing or disclosing same.

[saada]

Master Project I am against having a MASTER project. Context switching happens frequently when working with different microservices. This applies to the following points on Linting and SCM.

Persistence of workspace I think that on the first iteration, we shouldn't have to persist the workspace. I would prefer iterations on one or two releases for this feature before we introduce any settings or persistence layers to minimize any sorts of complex or destructive migrations.

Linting/Settings Project specific linting should be namespaced to files in the corresponding directories. For example, Project A uses prettier while Project B uses standard. Switching between both contexts should be seamless without linting rules conflicting with each other.

Search Loved some of the wireframes for this one where search results were across all projects and sorted by project.

_Project A_
file1: matched substring
file2: matched substring
...

_Project B_
file3: matched substring
file4: matched substring

SCM In this case, I'm leaning more towards showing a breakdown by project with each scm change.

_Project A_
file1: added
file2: removed
...

_Project B_
file3: moved
file4: added
file5: added

I feel like these approaches are more transparent and intuitive.

[glen-84]

The consensus (based on recent comments and other issues) seems to be against the idea of additionalFolders, at least in the initial release.

While I understand that the decision has already been made, would you consider attempting to implement this feature as a set of APIs, while leaving the persistence for a later iteration? So, APIs for adding/opening folders, and updates to the explorer, search, tasks, and SCM views to support this.

You have talked about how difficult it is to remove something from the product (if a project/workspace concept somehow failed), but the reality is that this applies equally (if not more so) to the additionalFolders concept.

Implementing both additionalFolders and "projects/workspaces" as extensions would allow you to gather usage data without committing to a single model. One of these extensions (or a hybrid solution) could later be integrated into the product.

[cliffrowley]

Have the issues with the environment been fixed on Mac OS? I'm still unable to use Homebrew npm and such without opening VSCode from the command line via code and this will play havoc with multi root support surely?

[akutz]

Yeah, this is a must for me too. I do not understand people's problems with it. It may not be the way one person works, but that doesn't mean another person's preferred workspace management is less valid. I just loathe answers of "Why do you want to do that?" instead of "Let's figure out how to add a feature that every other code editor in the world has."

Back to Atom I guess.