New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for opening multiple project folders in same window #396

Closed
stoffeastrom opened this Issue Nov 21, 2015 · 380 comments

Comments

Projects
None yet
@stoffeastrom

stoffeastrom commented Nov 21, 2015

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.

@i5ting

This comment has been minimized.

Show comment
Hide comment
@i5ting

i5ting Nov 21, 2015

agree, but maybe it is a optimize solution for memory

i5ting commented Nov 21, 2015

agree, but maybe it is a optimize solution for memory

@yoorek

This comment has been minimized.

Show comment
Hide comment
@yoorek

yoorek commented Nov 21, 2015

+1

@dmccaffery

This comment has been minimized.

Show comment
Hide comment
@dmccaffery

dmccaffery Nov 22, 2015

I'm not sure I understand the ask; its a lightweight code editor, not an IDE ... why would you need to open multiple "project" folders that aren't hierarchical (where you could set the working path to a mutual parent)?

If you're working on modules that are disparately stored on disk that are somehow interacting with each other to that degree, then they are too tightly coupled to begin with... are your projects siblings? If so, just open the parent folder, or parent / parent folder... wherever the root of your "solution" is.

dmccaffery commented Nov 22, 2015

I'm not sure I understand the ask; its a lightweight code editor, not an IDE ... why would you need to open multiple "project" folders that aren't hierarchical (where you could set the working path to a mutual parent)?

If you're working on modules that are disparately stored on disk that are somehow interacting with each other to that degree, then they are too tightly coupled to begin with... are your projects siblings? If so, just open the parent folder, or parent / parent folder... wherever the root of your "solution" is.

@stoffeastrom

This comment has been minimized.

Show comment
Hide comment
@stoffeastrom

stoffeastrom Nov 22, 2015

Well, if you have a number of modules (which are all in their own git repository) that is independent of each other but you have one repository that uses those dependencies it makes sense to be able to open these independent folders and make changes that would be reflected so you can test it locally. That would still be a lightweight code editor but a more useful one imho!

stoffeastrom commented Nov 22, 2015

Well, if you have a number of modules (which are all in their own git repository) that is independent of each other but you have one repository that uses those dependencies it makes sense to be able to open these independent folders and make changes that would be reflected so you can test it locally. That would still be a lightweight code editor but a more useful one imho!

@Tyriar

This comment has been minimized.

Show comment
Hide comment
@Tyriar

Tyriar Nov 22, 2015

Member

The main issue with setting the project as the parent is that git integration goes away, there are other valid use cases beyond both having a mutual parent as well though.

Member

Tyriar commented Nov 22, 2015

The main issue with setting the project as the parent is that git integration goes away, there are other valid use cases beyond both having a mutual parent as well though.

@dmccaffery

This comment has been minimized.

Show comment
Hide comment
@dmccaffery

dmccaffery Nov 22, 2015

@stoffeastrom sounds like a use case for submodules; I'm not sure how your project would reference another, unless you were aliasing with some mechanism, such as npm linking, etc. This problem is what package managers are largely intended to solve. If the modules are tightly coupled, then they really aren't isolated modules. You wouldn't be able to reliably make changes to support one project without worrying about the change having consequences for other consumers down the road. Even with submodules, they are read-only by default for exactly that reason.

At any rate, what @Tyriar just mentioned is one of the reasons I am wary of having this type of multi-working path interface in a single instance/window: you have to handle integrations (like git), extensions, refactoring, debugging, etc, etc, etc. all in some isolated fashion. For instance:

If I use the git integration to commit, am I committing project A or project B?
If I refactor a class name in TypeScript, should it refactor in project A or project B, or both? What if the same class name exists in both projects with different meanings? What if one is loosely referencing the other?

These are just some examples of how something seemingly simple can get very complicated, very quickly. I think it would be way more confusing and, frankly, less useful than to alt-tab/cmd+tab between a few separate instances of VSCode, each happily managing their own isolated working path without all the extra effort and edge case issues.

Im not saying that it couldn't be solved, but I don't quite understand why switching between multiple windows and/or instances is an issue. Maybe I am missing something...

dmccaffery commented Nov 22, 2015

@stoffeastrom sounds like a use case for submodules; I'm not sure how your project would reference another, unless you were aliasing with some mechanism, such as npm linking, etc. This problem is what package managers are largely intended to solve. If the modules are tightly coupled, then they really aren't isolated modules. You wouldn't be able to reliably make changes to support one project without worrying about the change having consequences for other consumers down the road. Even with submodules, they are read-only by default for exactly that reason.

At any rate, what @Tyriar just mentioned is one of the reasons I am wary of having this type of multi-working path interface in a single instance/window: you have to handle integrations (like git), extensions, refactoring, debugging, etc, etc, etc. all in some isolated fashion. For instance:

If I use the git integration to commit, am I committing project A or project B?
If I refactor a class name in TypeScript, should it refactor in project A or project B, or both? What if the same class name exists in both projects with different meanings? What if one is loosely referencing the other?

These are just some examples of how something seemingly simple can get very complicated, very quickly. I think it would be way more confusing and, frankly, less useful than to alt-tab/cmd+tab between a few separate instances of VSCode, each happily managing their own isolated working path without all the extra effort and edge case issues.

Im not saying that it couldn't be solved, but I don't quite understand why switching between multiple windows and/or instances is an issue. Maybe I am missing something...

@yoorek

This comment has been minimized.

Show comment
Hide comment
@yoorek

yoorek Nov 22, 2015

Sublime, Atom, Webstorm - they are also "lightweight" code editors (except maybe Webstorm) and they allow opening multiple root folders from different locations. These editors are probably 99% of what web developers use.
Code can compete with them with much better Typescript support (and it will be very popular consider Angular 2 is comming) but only if it will give developers what they use now as a basic functionality.

yoorek commented Nov 22, 2015

Sublime, Atom, Webstorm - they are also "lightweight" code editors (except maybe Webstorm) and they allow opening multiple root folders from different locations. These editors are probably 99% of what web developers use.
Code can compete with them with much better Typescript support (and it will be very popular consider Angular 2 is comming) but only if it will give developers what they use now as a basic functionality.

@daniel-uzunu

This comment has been minimized.

Show comment
Hide comment

daniel-uzunu commented Nov 22, 2015

+1

@nilzona

This comment has been minimized.

Show comment
Hide comment
@nilzona

nilzona commented Dec 2, 2015

+1

@egamma egamma modified the milestone: Backlog Dec 10, 2015

@bpasero bpasero added the workbench label Dec 18, 2015

@elgris

This comment has been minimized.

Show comment
Hide comment
@elgris

elgris Jan 3, 2016

As a Go developer, I find this feature extremely useful in Sublime or IntelliJ Idea. For instance, my small project imports code from Go core library or may import some 3rd party library. So I need to be able to quickly navigate to them and read that code.

elgris commented Jan 3, 2016

As a Go developer, I find this feature extremely useful in Sublime or IntelliJ Idea. For instance, my small project imports code from Go core library or may import some 3rd party library. So I need to be able to quickly navigate to them and read that code.

@rezonant

This comment has been minimized.

Show comment
Hide comment
@rezonant

rezonant Feb 28, 2016

+1. Multi-git repo microservice solutions are very painful in VS Code right now, thinking of finding another Typescript-capable IDE instead.

rezonant commented Feb 28, 2016

+1. Multi-git repo microservice solutions are very painful in VS Code right now, thinking of finding another Typescript-capable IDE instead.

@TurkeyMan

This comment has been minimized.

Show comment
Hide comment
@TurkeyMan

TurkeyMan Mar 8, 2016

We definitely need some sort of 'solution'. I'm a native dev, and this almost always involves building a set of libs/dll's and then referring to them from some host app project.
Once we have multiple projects, we also need a 'startup project' for when we press 'run'.

TurkeyMan commented Mar 8, 2016

We definitely need some sort of 'solution'. I'm a native dev, and this almost always involves building a set of libs/dll's and then referring to them from some host app project.
Once we have multiple projects, we also need a 'startup project' for when we press 'run'.

@bpasero bpasero changed the title from feature request: add support for opening multiple project folders to Add support for opening multiple project folders Mar 14, 2016

@bpasero bpasero self-assigned this Mar 30, 2016

@Loren-Johnson

This comment has been minimized.

Show comment
Hide comment
@Loren-Johnson

Loren-Johnson Apr 21, 2016

I would also like support for projects and multiple git roots. The code I frequently use is found in several git repos and being unable to switch between them without closing my current workspace and opening another just to turn around and close that one to open the previous is exhausting. If I add the parent folder where all my repos are housed then I gain the ability to navigate and search among my files but I lose git integration. It's a real bummer.

The line between "text editor" and "IDE" is pretty dang blurry and I don't really care what VS Code is labeled as. What I do care about is what a tool can do and how painless it is to use. I think adding project support would alleviate a lot of friction for folks like me.

Loren-Johnson commented Apr 21, 2016

I would also like support for projects and multiple git roots. The code I frequently use is found in several git repos and being unable to switch between them without closing my current workspace and opening another just to turn around and close that one to open the previous is exhausting. If I add the parent folder where all my repos are housed then I gain the ability to navigate and search among my files but I lose git integration. It's a real bummer.

The line between "text editor" and "IDE" is pretty dang blurry and I don't really care what VS Code is labeled as. What I do care about is what a tool can do and how painless it is to use. I think adding project support would alleviate a lot of friction for folks like me.

@rhbecker

This comment has been minimized.

Show comment
Hide comment
@rhbecker

rhbecker Apr 21, 2016

I also would like to see the git integration work when your workspace contains multiple repos, but I just want to make sure folks like @Loren-Johnson realize they can have multiple vs code windows open simultaneously.

This is in response to: "unable to switch between them without closing my current workspace"

rhbecker commented Apr 21, 2016

I also would like to see the git integration work when your workspace contains multiple repos, but I just want to make sure folks like @Loren-Johnson realize they can have multiple vs code windows open simultaneously.

This is in response to: "unable to switch between them without closing my current workspace"

@bpasero bpasero closed this Apr 27, 2016

@bpasero bpasero reopened this Apr 27, 2016

@stoffeastrom

This comment has been minimized.

Show comment
Hide comment
@stoffeastrom

stoffeastrom Apr 27, 2016

You mean #2686 is a duplicate of this?

stoffeastrom commented Apr 27, 2016

You mean #2686 is a duplicate of this?

@bpasero

This comment has been minimized.

Show comment
Hide comment
@bpasero

bpasero Apr 27, 2016

Member

Sorry, I misread the description and reopened this one.

Member

bpasero commented Apr 27, 2016

Sorry, I misread the description and reopened this one.

@Sapunov

This comment has been minimized.

Show comment
Hide comment
@Sapunov

Sapunov commented May 19, 2016

+1

@lepinkainen

This comment has been minimized.

Show comment
Hide comment
@lepinkainen

lepinkainen May 31, 2016

Is there any progress on this issue, or at least some statement if this will ever be implemented? Are there some low-level decisions in the code that prevent multiple roots in one project?

This is pretty much the only reason I'm not moving from ST3 to VSCode.

lepinkainen commented May 31, 2016

Is there any progress on this issue, or at least some statement if this will ever be implemented? Are there some low-level decisions in the code that prevent multiple roots in one project?

This is pretty much the only reason I'm not moving from ST3 to VSCode.

This was referenced Jun 14, 2016

@brusbilis

This comment has been minimized.

Show comment
Hide comment
@brusbilis

brusbilis commented Jun 28, 2016

+1

@josebalius

This comment has been minimized.

Show comment
Hide comment
@josebalius

josebalius commented Jun 29, 2016

+1

@mibanez

This comment has been minimized.

Show comment
Hide comment
@mibanez

mibanez commented Jul 4, 2016

+1

@bpasero bpasero changed the title from Add support for opening multiple project folders to Add support for opening multiple project folders in same window Jul 5, 2016

@matthewatabet

This comment has been minimized.

Show comment
Hide comment
@matthewatabet

matthewatabet Jul 6, 2016

+1 this would be very helpful. The suggestion to use git submodules is very inconvenient. Would love to have this feature.

matthewatabet commented Jul 6, 2016

+1 this would be very helpful. The suggestion to use git submodules is very inconvenient. Would love to have this feature.

@kalinkrustev

This comment has been minimized.

Show comment
Hide comment
@kalinkrustev

kalinkrustev Jul 6, 2016

An initial lightweight approach would be something similar to what git-project-manager extension does. The approach could be to basically switch the context/root for what git sees as changes, but without changing the context/root for what file browser sees. This extension works perfect, just needs a tighter integration to make the switching faster.

kalinkrustev commented Jul 6, 2016

An initial lightweight approach would be something similar to what git-project-manager extension does. The approach could be to basically switch the context/root for what git sees as changes, but without changing the context/root for what file browser sees. This extension works perfect, just needs a tighter integration to make the switching faster.

@xcorpio

This comment has been minimized.

Show comment
Hide comment
@xcorpio

xcorpio commented Jul 7, 2016

+1

@shoerob

This comment has been minimized.

Show comment
Hide comment
@shoerob

shoerob Jul 7, 2016

+1 - I started going down the path of using git submodules, but it feels like more of a hack than an actual solution.

shoerob commented Jul 7, 2016

+1 - I started going down the path of using git submodules, but it feels like more of a hack than an actual solution.

@fgallardograzio

This comment has been minimized.

Show comment
Hide comment
@fgallardograzio

fgallardograzio Sep 19, 2017

@bpasero IMHO, the way UI states are handled (weather it's using an ID string in the .code-workspace file, or using the file path as the ID instead) is not adequate.
Renaming a .code-workspace file, or any of its parent folders, or moving it around, and losing the UI state is in my opinion totally unintuitive. I think people unaware of how that works under the hood would have absolutely no clue about the reason they lost their previous UI state and how to get it back.
That should not be tied to the absolute path of the files in the file system at all!

This applies to the way UI state relates to folder path currently in the stable release as well. I was very confused about that at first, until I did some googling.

IMO In case we're dealing with just one folder, UI state should be saved inside the .vscode folder. If we're dealing with a multi-root workspace, UI state should be saved as a separate file in the same folder as the .code-workspace file using appropriate naming conventions (or maybe inside that file itself, although mixing settings and state might not be a good idea).

If correctly implemented, this would allow users to have complete access to UI states, attach new UI states to a given workspace (multi-root or not), etc.
I'd love to be able to sync UI state between different computers, say working in the office, then going home, grabbing a laptop or whatever and continuing exactly where I left off.
Having several UI states attached to a workspace and easily switch between them (menu/keybinding/command/etc) when working on different features would be awesome as well. Perhaps different .code-uistate files inside .vscode listed automatically, or many .code-uistate files prefixed according to the main .code-workspace, or listed in an array.

I'm thinking about this as an extension of how projects and workspaces work on Sublime Text. Same functionality, different design. In this case a VS Code workspace would be similar to a Sublime project, and the different VS Code UI states would be similar to Sublime workspaces.

Regarding this issues:

it was weird that you could edit the id in the file simply by typing another value

Yes, totally. Removing the ID from there was the right choice.

it was not very clear how to treat the id when sharing the workspace file with others (should the id be changed? should the id be a uuid?)

Well, if we've got myproject.code-workspace and myproject.code-uistate then it's up to the user to decide whether to share their UI State or not. No more thinking what that ID means, how it's generated, if it needs to be a UUID to avoid conflicts when sharing, etc.
Want to share folder setup and settings? Send myproject.code-workspace, no need to worry.
Want to share everything? Send both files.

it was not possible to copy a workspace file and open it in a separate window, you had to change the id first in the copied file

If you want to start with a fresh UI state with the same folder setup and settings just duplicate your .code-workspace file.

as a consequence, the "Save Workspace As" action would have to ask the user if the copy should have a different id or not

That was tricky since the user didn't know what that ID was. Perhaps it'd be more straightforward to have two options "Clone Workspace with Current State" and "New Blank Workspace". But that's UX and you'd have to do an analysis about that.

fgallardograzio commented Sep 19, 2017

@bpasero IMHO, the way UI states are handled (weather it's using an ID string in the .code-workspace file, or using the file path as the ID instead) is not adequate.
Renaming a .code-workspace file, or any of its parent folders, or moving it around, and losing the UI state is in my opinion totally unintuitive. I think people unaware of how that works under the hood would have absolutely no clue about the reason they lost their previous UI state and how to get it back.
That should not be tied to the absolute path of the files in the file system at all!

This applies to the way UI state relates to folder path currently in the stable release as well. I was very confused about that at first, until I did some googling.

IMO In case we're dealing with just one folder, UI state should be saved inside the .vscode folder. If we're dealing with a multi-root workspace, UI state should be saved as a separate file in the same folder as the .code-workspace file using appropriate naming conventions (or maybe inside that file itself, although mixing settings and state might not be a good idea).

If correctly implemented, this would allow users to have complete access to UI states, attach new UI states to a given workspace (multi-root or not), etc.
I'd love to be able to sync UI state between different computers, say working in the office, then going home, grabbing a laptop or whatever and continuing exactly where I left off.
Having several UI states attached to a workspace and easily switch between them (menu/keybinding/command/etc) when working on different features would be awesome as well. Perhaps different .code-uistate files inside .vscode listed automatically, or many .code-uistate files prefixed according to the main .code-workspace, or listed in an array.

I'm thinking about this as an extension of how projects and workspaces work on Sublime Text. Same functionality, different design. In this case a VS Code workspace would be similar to a Sublime project, and the different VS Code UI states would be similar to Sublime workspaces.

Regarding this issues:

it was weird that you could edit the id in the file simply by typing another value

Yes, totally. Removing the ID from there was the right choice.

it was not very clear how to treat the id when sharing the workspace file with others (should the id be changed? should the id be a uuid?)

Well, if we've got myproject.code-workspace and myproject.code-uistate then it's up to the user to decide whether to share their UI State or not. No more thinking what that ID means, how it's generated, if it needs to be a UUID to avoid conflicts when sharing, etc.
Want to share folder setup and settings? Send myproject.code-workspace, no need to worry.
Want to share everything? Send both files.

it was not possible to copy a workspace file and open it in a separate window, you had to change the id first in the copied file

If you want to start with a fresh UI state with the same folder setup and settings just duplicate your .code-workspace file.

as a consequence, the "Save Workspace As" action would have to ask the user if the copy should have a different id or not

That was tricky since the user didn't know what that ID was. Perhaps it'd be more straightforward to have two options "Clone Workspace with Current State" and "New Blank Workspace". But that's UX and you'd have to do an analysis about that.

@danielsokolowski

This comment has been minimized.

Show comment
Hide comment
@danielsokolowski

danielsokolowski Sep 19, 2017

danielsokolowski commented Sep 19, 2017

@pr-yemibedu

This comment has been minimized.

Show comment
Hide comment
@pr-yemibedu

pr-yemibedu Sep 19, 2017

Contributor

@danielsokolowski I understand the notion of a project overwriting a workspace for settings. In vscode you have general settings, user settings (over writing general), and workspace settings (over writing user or general). Each project already has the opportunity to have its own .vscode folder (workspace settings live in it). Are you suggesting an additional folder that would nest projects just to share settings information? That would seem similar to a "solution" file/folder in visual studio terms.

@fgallardograzio Having a project configuration intermingled with settings in the same file will force coupling. The ui stuff sounds a lot better as another feature separate from this issue ticket. Now that the Insiders build has some nice layout of the extra roots in the file, maybe an extension can fill in the gap for the ui part. Thank you. Good day.

Contributor

pr-yemibedu commented Sep 19, 2017

@danielsokolowski I understand the notion of a project overwriting a workspace for settings. In vscode you have general settings, user settings (over writing general), and workspace settings (over writing user or general). Each project already has the opportunity to have its own .vscode folder (workspace settings live in it). Are you suggesting an additional folder that would nest projects just to share settings information? That would seem similar to a "solution" file/folder in visual studio terms.

@fgallardograzio Having a project configuration intermingled with settings in the same file will force coupling. The ui stuff sounds a lot better as another feature separate from this issue ticket. Now that the Insiders build has some nice layout of the extra roots in the file, maybe an extension can fill in the gap for the ui part. Thank you. Good day.

@danielsokolowski

This comment has been minimized.

Show comment
Hide comment
@danielsokolowski

danielsokolowski Sep 20, 2017

danielsokolowski commented Sep 20, 2017

@JamesTheHacker

This comment has been minimized.

Show comment
Hide comment
@JamesTheHacker

JamesTheHacker Sep 24, 2017

Is this feature still not added?

This is very important for me. I am working on a project that is composed of 2 separate repositories: the web frontend, and the api. It would be nice if I could open both of these folders in a single "project".

Sure, I could solve this by cloning the 2 repos into a single folder and opening that folder but this doesn't work for every case. Especially if you have multiple projects that depend on a single repository (i.e. share the same API).

This feature would also be useful for those who use code as documentation.

JamesTheHacker commented Sep 24, 2017

Is this feature still not added?

This is very important for me. I am working on a project that is composed of 2 separate repositories: the web frontend, and the api. It would be nice if I could open both of these folders in a single "project".

Sure, I could solve this by cloning the 2 repos into a single folder and opening that folder but this doesn't work for every case. Especially if you have multiple projects that depend on a single repository (i.e. share the same API).

This feature would also be useful for those who use code as documentation.

@Jeyanthinath

This comment has been minimized.

Show comment
Hide comment
@Jeyanthinath

Jeyanthinath Sep 25, 2017

Contributor

@JamesTheHacker for a while use vscode-insiders which support multiple projects at same time. And you can suggest features depending on what you feel with the insider version to make it better

Contributor

Jeyanthinath commented Sep 25, 2017

@JamesTheHacker for a while use vscode-insiders which support multiple projects at same time. And you can suggest features depending on what you feel with the insider version to make it better

@borekb

This comment has been minimized.

Show comment
Hide comment
@borekb

borekb Sep 25, 2017

When this ships, VSCode version should probably bump to 2.0. Just saying :)

borekb commented Sep 25, 2017

When this ships, VSCode version should probably bump to 2.0. Just saying :)

@giltayar

This comment has been minimized.

Show comment
Hide comment
@giltayar

giltayar Sep 26, 2017

Quick question regarding this feature:

This feature supports adding multiple folders with repositories to an existing workspace. Would it also support a mono-repo configuration, whereby I want to open multiple projects in a mono-repo, but since they are in one repo, they don't have a git repo of their own. So from a project point of view, they don't have a .git folder - one of the ancestor folders has them.

You might ask why not open the mono-repo folder as one big folder and just work in there? There are two answers:

  1. (less interesting for me) there are too many projects in the mono-repo, and I'm interested only in some of them.
  2. Many plugins assume that a project contains only one... project. For example, only one npm package. So they look for things in the root of the project. Examples: the npm plugin for VSCode, the mocha plugin for vscode, and lots of functionality in VSCode itself - for example, I can't specify a path in the launch.json that is relative to the current file, i.e. "the node_modules folder that is the nearest ancestor of the current file".

After this contextual explanation, my question is simple - would this feature support projects who's .git folder is an ancestor of their root? If so, then it would be possible to use this feature in a mono-repo.

giltayar commented Sep 26, 2017

Quick question regarding this feature:

This feature supports adding multiple folders with repositories to an existing workspace. Would it also support a mono-repo configuration, whereby I want to open multiple projects in a mono-repo, but since they are in one repo, they don't have a git repo of their own. So from a project point of view, they don't have a .git folder - one of the ancestor folders has them.

You might ask why not open the mono-repo folder as one big folder and just work in there? There are two answers:

  1. (less interesting for me) there are too many projects in the mono-repo, and I'm interested only in some of them.
  2. Many plugins assume that a project contains only one... project. For example, only one npm package. So they look for things in the root of the project. Examples: the npm plugin for VSCode, the mocha plugin for vscode, and lots of functionality in VSCode itself - for example, I can't specify a path in the launch.json that is relative to the current file, i.e. "the node_modules folder that is the nearest ancestor of the current file".

After this contextual explanation, my question is simple - would this feature support projects who's .git folder is an ancestor of their root? If so, then it would be possible to use this feature in a mono-repo.

@Guema

This comment has been minimized.

Show comment
Hide comment
@Guema

Guema Sep 26, 2017

@borekb Yeah. I don't know how people at Microsoft manage their versions, but i think it's a massive enough feature for a major

Guema commented Sep 26, 2017

@borekb Yeah. I don't know how people at Microsoft manage their versions, but i think it's a massive enough feature for a major

@joaomoreno

This comment has been minimized.

Show comment
Hide comment
@joaomoreno

joaomoreno Sep 26, 2017

Member

After this contextual explanation, my question is simple - would this feature support projects who's .git folder is an ancestor of their root? If so, then it would be possible to use this feature in a mono-repo.

This is already supported since quite a long time, if you simply open a subfolder of a git repo.

Member

joaomoreno commented Sep 26, 2017

After this contextual explanation, my question is simple - would this feature support projects who's .git folder is an ancestor of their root? If so, then it would be possible to use this feature in a mono-repo.

This is already supported since quite a long time, if you simply open a subfolder of a git repo.

@inestyne

This comment has been minimized.

Show comment
Hide comment
@inestyne

inestyne Sep 26, 2017

+1

Sublime and Atom do it you should to. No better reason. This is the NEW MS, get it done guys, i have complete faith in you. :)

inestyne commented Sep 26, 2017

+1

Sublime and Atom do it you should to. No better reason. This is the NEW MS, get it done guys, i have complete faith in you. :)

@pr-yemibedu

This comment has been minimized.

Show comment
Hide comment
@pr-yemibedu

pr-yemibedu Sep 27, 2017

Contributor

Hello,
@inestyne if you please read prior posts like from @Jeyanthinath you would be aware of using VSCode Insiders to evaluate this feature already. There is even a roadmap to check. So please use the product and provide feedback before it migrates to stable so we all get the best product possible. Thank you. Good day.

Contributor

pr-yemibedu commented Sep 27, 2017

Hello,
@inestyne if you please read prior posts like from @Jeyanthinath you would be aware of using VSCode Insiders to evaluate this feature already. There is even a roadmap to check. So please use the product and provide feedback before it migrates to stable so we all get the best product possible. Thank you. Good day.

@nahuelhds

This comment has been minimized.

Show comment
Hide comment
@nahuelhds

nahuelhds Sep 27, 2017

Just read the thread and use Insiders OMG. I'm gonna unsubscribe... you trolls that doesn't read are impossible. Thanks @pr-yemibedu

nahuelhds commented Sep 27, 2017

Just read the thread and use Insiders OMG. I'm gonna unsubscribe... you trolls that doesn't read are impossible. Thanks @pr-yemibedu

@inestyne

This comment has been minimized.

Show comment
Hide comment
@inestyne

inestyne commented Sep 27, 2017

Sensitive

@bitblitz

This comment has been minimized.

Show comment
Hide comment
@bitblitz

bitblitz Oct 6, 2017

Since this thread is 2 years long, and the feature seems to be in the Insiders' build now, is there a way to mark this thread so that is more obvious than reading the entire thread from the top?

bitblitz commented Oct 6, 2017

Since this thread is 2 years long, and the feature seems to be in the Insiders' build now, is there a way to mark this thread so that is more obvious than reading the entire thread from the top?

@jearle

This comment has been minimized.

Show comment
Hide comment
@jearle

jearle Oct 20, 2017

One thing that is missing is the ability to open up a new window with a new workspace from the CLI.

jearle commented Oct 20, 2017

One thing that is missing is the ability to open up a new window with a new workspace from the CLI.

@Tyriar

This comment has been minimized.

Show comment
Hide comment
@Tyriar

Tyriar Oct 20, 2017

Member

@jearle A new window/workspace should be created as before with code-insiders <folder>, no?
code-insiders -a <folder> is needed to add the folder to the current window.

Member

Tyriar commented Oct 20, 2017

@jearle A new window/workspace should be created as before with code-insiders <folder>, no?
code-insiders -a <folder> is needed to add the folder to the current window.

@jhonnymoreira

This comment has been minimized.

Show comment
Hide comment
@jhonnymoreira

jhonnymoreira Oct 21, 2017

@Jeyanthinath thanks! Been doing the same thing as @JamesTheHacker and it will help me!

jhonnymoreira commented Oct 21, 2017

@Jeyanthinath thanks! Been doing the same thing as @JamesTheHacker and it will help me!

@jearle

This comment has been minimized.

Show comment
Hide comment
@jearle

jearle Oct 23, 2017

@Tyriar to get the functionality I wanted I have to execute the following commands:

code .; code -a .

code . opens the folder as a non workspace, and then the code -a . attaches it's self to the previously open window as a workspace allowing me to open the same folder more than once.

jearle commented Oct 23, 2017

@Tyriar to get the functionality I wanted I have to execute the following commands:

code .; code -a .

code . opens the folder as a non workspace, and then the code -a . attaches it's self to the previously open window as a workspace allowing me to open the same folder more than once.

@dark-swordsman

This comment has been minimized.

Show comment
Hide comment
@dark-swordsman

dark-swordsman Oct 27, 2017

I personally think this also needs to be changed. I am working with ionic and a custom server in two different git repos and it's not very easy. The ability to at least have two separate "project tabs" open or something would be great.

I switched from Atom because of how buggy and slow it was.

dark-swordsman commented Oct 27, 2017

I personally think this also needs to be changed. I am working with ionic and a custom server in two different git repos and it's not very easy. The ability to at least have two separate "project tabs" open or something would be great.

I switched from Atom because of how buggy and slow it was.

@felixfbecker

This comment has been minimized.

Show comment
Hide comment
@felixfbecker

felixfbecker Oct 27, 2017

Contributor

@dark-swordsman you can enable nativeTabs on mac

Contributor

felixfbecker commented Oct 27, 2017

@dark-swordsman you can enable nativeTabs on mac

@dark-swordsman

This comment has been minimized.

Show comment
Hide comment
@dark-swordsman

dark-swordsman Oct 30, 2017

@felixfbecker is this possible on Windows?

Edit: I searched through the settings file completely and there is no option for that. That's why I'm asking.

Edit2: Also, there isn't a clear resource on how to enable vs insiders

dark-swordsman commented Oct 30, 2017

@felixfbecker is this possible on Windows?

Edit: I searched through the settings file completely and there is no option for that. That's why I'm asking.

Edit2: Also, there isn't a clear resource on how to enable vs insiders

@pr-yemibedu

This comment has been minimized.

Show comment
Hide comment
@pr-yemibedu

pr-yemibedu Oct 30, 2017

Contributor

Hello,
@dark-swordsman you do not enable VS Insiders. It is a build of VSCode that has some extra features that have not finalized to stable and in a way gives you an extra editor namespace to work with (You can install them side by side without conflicts of settings or extensions). Thank you. Good day.

Contributor

pr-yemibedu commented Oct 30, 2017

Hello,
@dark-swordsman you do not enable VS Insiders. It is a build of VSCode that has some extra features that have not finalized to stable and in a way gives you an extra editor namespace to work with (You can install them side by side without conflicts of settings or extensions). Thank you. Good day.

@bpasero

This comment has been minimized.

Show comment
Hide comment
@bpasero

bpasero Nov 2, 2017

Member

Support for multi-root workspaces is now enabled by default in the stable release.

panel-red2

Please refer to our documentation for a full explanation of all the features that come with it. Extension authors should refer to our wiki that explains the new extension APIs to make your extension ready for multi-root workspaces. We are happy that quite some extensions have already started to adopt the new multi-root API, thanks for that!

Please do not hesitate to file issues for multi-root as you encounter them, we are still planning on making tweaks and providing additional APIs for extensions to work with multi-root workspaces in the future.

Member

bpasero commented Nov 2, 2017

Support for multi-root workspaces is now enabled by default in the stable release.

panel-red2

Please refer to our documentation for a full explanation of all the features that come with it. Extension authors should refer to our wiki that explains the new extension APIs to make your extension ready for multi-root workspaces. We are happy that quite some extensions have already started to adopt the new multi-root API, thanks for that!

Please do not hesitate to file issues for multi-root as you encounter them, we are still planning on making tweaks and providing additional APIs for extensions to work with multi-root workspaces in the future.

@dark-swordsman

This comment has been minimized.

Show comment
Hide comment
@dark-swordsman

dark-swordsman Nov 2, 2017

This is great, but when will it be available? You say it's in the stable build, but I have the latest Stable build (1.17.2) and can't update to it. Also, in the documentation that you just referenced, it said it's still in the Insider's build and will be in the stable release soon.

I understand it may be a small while before the next build is released, but I saw this notification expecting it to be available. Sorry if I'm being impatient, I am just getting to a point in my current project where this is extremely necessary and is partially responsible for preventing me to continue.

Edit: I apologize for my impatience. I was just trying to open a new window the manual way (call the .exe again) and it wasn't working, but didn't look in File > Open New Window. This will work for now. Looking forward to the release of the next build. 👍

dark-swordsman commented Nov 2, 2017

This is great, but when will it be available? You say it's in the stable build, but I have the latest Stable build (1.17.2) and can't update to it. Also, in the documentation that you just referenced, it said it's still in the Insider's build and will be in the stable release soon.

I understand it may be a small while before the next build is released, but I saw this notification expecting it to be available. Sorry if I'm being impatient, I am just getting to a point in my current project where this is extremely necessary and is partially responsible for preventing me to continue.

Edit: I apologize for my impatience. I was just trying to open a new window the manual way (call the .exe again) and it wasn't working, but didn't look in File > Open New Window. This will work for now. Looking forward to the release of the next build. 👍

@karuppasamy

This comment has been minimized.

Show comment
Hide comment
@karuppasamy

karuppasamy Nov 10, 2017

@bpasero Please close this #35849 open issue since the expected functionality has done as part this #396 feature.

karuppasamy commented Nov 10, 2017

@bpasero Please close this #35849 open issue since the expected functionality has done as part this #396 feature.

@DJManas

This comment has been minimized.

Show comment
Hide comment
@DJManas

DJManas Nov 11, 2017

Just a quick question. Is it possible, when I have opened more folders, to switch which folder I want to compile? At the moment it is always the first one in stable version.

EDIT: This might be for the creator of PlatformIO extension, but I am asking on both sides. Just in case...

DJManas commented Nov 11, 2017

Just a quick question. Is it possible, when I have opened more folders, to switch which folder I want to compile? At the moment it is always the first one in stable version.

EDIT: This might be for the creator of PlatformIO extension, but I am asking on both sides. Just in case...

@bpasero

This comment has been minimized.

Show comment
Hide comment
@bpasero

bpasero Nov 13, 2017

Member

@DJManas it sounds like that this is up to the extension you are using to decide, so you should ask the author of the extension.

Member

bpasero commented Nov 13, 2017

@DJManas it sounds like that this is up to the extension you are using to decide, so you should ask the author of the extension.

@DJManas

This comment has been minimized.

Show comment
Hide comment
@DJManas

DJManas Nov 13, 2017

@bpasero Ok, I did in parallel, thank you for reply.

DJManas commented Nov 13, 2017

@bpasero Ok, I did in parallel, thank you for reply.

@vscodebot vscodebot bot locked and limited conversation to collaborators Dec 17, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.