Closed stoffeastrom closed 7 years ago
Please prefer :+1: reactions on the original issue comment as that helps us with prioritization and doesn't send notifications to everyone listening to the issue for updates.
+1
I am currently using Sublime, and trying out Code. It looks and feels nice, but the single project Git integration is a deal breaker. I have a Hadoop/Oozie project, and so have one repo of code, and another of working notes. In Sublime, I have them both open in the same window, and can commit to the appropriate Git repo for each
so, it'll be good to add
+1 yep, critical in microservice world it's usual to have 3..4 repos open at the same time
Weekly Reminder: Stop posting comments with +1. They are clutter and only serve to annoy people following this issue. Instead, give a thumbs up to the initial issue, which is actually counted.
I know you all meant well. So feel free to delete your +1 comment so it's not taking up space in this important historical record, too!
@jamietre I've tried... hard:
Maybe another alternative is to lock down this issue but keep open until resolved? This way, we know the importance of the issue (I'd say we already got enough +1's for it), but can't add to the clutter/redundancy (e.g. no more commenting allowed).
Although that's a rarely used feature I think, I only came across the lockdown on one public project/repo on Github.
The lockdown could be unlocked when deemed necessary, if ever.
@daluu this is how the /aspnet/announcement repo works; every issue is immediately locked. That being said, GitHub should do something in the UI to at least drive people toward alternatives beyond just "+1" as reactions now exist. 👍
把多窗口这个功能整上把,看两个项目以上的文档时,很有帮助,
interesting approach to the problem. I was a VB/.net programmer for many years, loved the languages and the tools, but have been away for a few years in Hadoop/Spark/Scala/Intellij/Sublime-land. I still listen to DotNetRocks, like to keep up to date with what's going on, and was interested to hear about this Code app. On the positive side, it's a very nice editor, with some nice looking Git features, but that's totally irrelevant unfortunately. Because it doesn't handle Git for multiple projects in the same workspace, as Sublime very elegantly does, then I just can't use it
That happens. What I am most surprised by is the reaction here, first to claim that this isn't a necessary feature, and then most of the discussion now seems to be around "how can we stop people posting +1"
I'll tell you how you do that - you fix a basic problem that was first raised a whole year ago! It's called "listening to feedback". Just because you're not personally affected by a problem, it doesn't mean it doesn't exist. If you don't want a particular group of users to use the app, then fine, but don't give us a feedback mechanism, then dispute our problem and then get annoyed with us for keeping asking for it.
I'm back to using Sublime
The "+ 1" issue can be fixed with the following code: if (post_message == "+1") { add_smiley_reaction(); delete_post_message(); }
Dear GitHub, I'm available for hire.
yeah, this is never going to get fixed, is it. Far easier to mock and ignore "+1" comments rather than actually address the core problem, software being marketed to a particular section of developers that doesn't do what it needs to for them to be productive ...
just read this one "Every direct reply to this comment (=more meta) will result in me blocking the user." - now, that's how to manage feedback! Stick your fingers in your ears and say "can't hear you!"
dear lord
@kryps1 then people will add "+ 1" or "++1" or "1+" or "bump" or "Yes, please. +1". Whatever you would do people will find a way around that. Is not as easy as you think.
Stop with the useless debate of +1
's please... Focus on what's needed here, which is multiple projects in the explorer.
For the git
problem, it just has to be splitted the same way the explorer is (ie by cwd).
Let's not start a flame war over the +1 stuff. It would definitely be nice if this issue was given priority.
But would like to mention to the community, I assume PRs and contributions are welcome ;-) someone can go patch/fix the code if the core developers don't get to it. I had some of my projects improved upon (with forks) because the user/developer rather do it themselves than wait on me to make improvements that they would like to suggest to me. So anyone that annoyed by this issue and capable/skilled enough, please fix (then submit a PR)? lol
And back to the +1 topic, bumping up issue and adding your opinion is good, but the +1 is a lame way to do it if there's other methods available like the thumbs up feature. Consider a Facebook post, or the original Google+ post, and users/readers go add a +1 comment instead of clicking Like (or one of Facebook's new reactions), or +1 for Google+. Over time that's a long comment thread of lame +1s, where as I reader I might be scrolling to view interesting comments but I end up seeing bunch of +1s. This is what was happening here, I'd prefer not to see/read through these +1s, whether I'm a project developer or just a user (or researching this project for potential use).
On a related note, here's a silly (but good intention) use of a GH issue, thank god, people didn't all go +1 on it though: https://github.com/sinatra/sinatra/issues/920
I assume PRs and contributions are welcome
Not really. See this comment from August: https://github.com/Microsoft/vscode/issues/396#issuecomment-241806158
Apparently this issue is in the Roadmap since at least then, but there has been no progress on it. It would be nice to hear a status update from the VSCode team.
For me, and this is trying to get the topic back on track, multiple project folders is needed.
In Atom, it supports GIT, and the only way I use it is to note which files have changes. I have a Rackspace server that won't allow SSH so manual uploads I go. However, I am able to have multiple project folders in the sidebar, and it makes it so much easier to reference code I've used in a previous project. Or switch gears to another project if I need a breather.
With VSCode, the issue that's preventing me from swtiching, and man do I wanna switch, is that lack of multiple project folders in the side bar.
I mean I guess I could just open the root folder to temporarily resolve it, but if I only need 3/20 folders, and I don't wanna see the loose files, then this should be an easy implementation, right?
Update: The big workbench update coming soon is hot exit (#101), while working on hot exit we've been actively discussing this issue to ensure the design takes multiple folders into consideration.
This issue is currently number 2 in terms of :+1: reactions of all issues (number 1 by a long way tagged workbench), as such this is very likely the next large piece of work for the workbench after hot exit.
On :+1: comments; they only serve to annoy the 80+ people subscribed to the issue. Voting on the issue with a reaction however is one of the most powerful things you can do to influence the project.
Also keep in mind we're a relatively small team and that the cleanliness of the codebase and performance of vscode is very important, so things take time to do right. Particularly for something like this which is a fundamental change to how vscode has been build to date, there's quite a bit of work in this issue.
+1
Indeed that would be a handy feature.
I switched from Atom and really liked it, but i work on two UI applications and another 2 SDK's, but the inability of changing between those projects (or folders) quickly is a important lack, i guess that i should go back to Atom until this got resolved
I'm really looking forward to this feature~~~
I'm a golang develper using vscode, hope this has an implement, thx!
I am trying to switch from Sublime to VScode. And soon I discovered VScode not supporting multiple folders in a "project" concept is really a problem blocking me form doing so.
Really love the other features of this "light weight" editor. Meanwhile I believe supporting multiple folders in a "project" wouldn't make VScode "overweight" or "IDE-like". It would just make it more convenient for developers using other editors to make the transition much less painful.
Hope to have this improvement. Thanks!
Also if the team can add the ability to save project based settings which overrides default settings that will be great. The usecase is if I can have different interpreters for different projects. Similarly having different tab sizes etc will also help. Please let me know if this can already be achieved in some way.
As a developer we are always working on multiple projects and we have side projects of our own. Customizing project settings(workspace settings for vscode) every time I switch project is a big pain.
@bajubullet You should try https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig Not sure if it covers everything that you need, but it's a start.
@danechitoaie thanks for the response. EditorConfig doesn't help though, i can specify properties per filetype but if I can save them in as project settings it will be easier and I don't like having .editorconfig for every project. Also in case of extensions like the python extension which let's us provide the interpreter to be used this will not help because python.pythonPath is not supported through editorconfig. Please let me know if I am missing something here. Any suggestions are most welcome.
I agree, I'm also really looking forward for some kind of project specific settings and being able to open multiple "root" folders. It's the only things I miss from Sublime.
This is being Implemented soon!
So no need to keep adding to this post. If you have other issues create a new thread. Thanks!
This is quite a long thread and I read through maybe a third of it, but just want to voice my support. I just installed VS Code with https://github.com/JuliaEditorSupport/julia-vscode as a possible substitute for Atom/Juno. It's beautiful! 😍
When developing Julia code, however, I feel it is pretty important to be able to open multiple packages in different folders. In principle, I could open the folder above, but that would expose the 100s of Julia packages I have installed. I could also change my LOAD_PATH, but I'd much prefer a VS Code solution.
I sincerely hope to be able to open multiple folders. Thank you for the efforts 👍
Hi everyone, as you may have noticed we are exploring the implementation of this issue during this iteration.
From https://github.com/Microsoft/vscode/issues/17608
Investigate into multi root workspaces across the different components @team
I'm looking to chat to 3-5 of you about your use cases as we think through the implementation details. Please sign up for a 15 minute time slot next Tuesday if you can. I would love to chat.
switching between my api and ui is making me crazy... :-(
@ehartford any reason in particular they don't share a mutual parent?
Yes. Git integration doesn't work if I just open the parent directory.
@ehartford good reason :smile:
@waderyan are you looking for end user use cases only, or extension developers too?
As an end user the multi folder support was useful most of the times for searching purposes. I used to create Projects adding different folders from different APIs, just for making searches easier (unified). I would say I don't miss that much today, and doesn't bother me to have multiple VSCode windows today, specially after Switch Window
command was added :+1:
As extension developer I have some extensions that are based on Project Context, like context.workspaceState
, activationEvents/workspaceContains
. And also Project Manager, which by the way I already started refactoring the internals to support multi folder. I would love to know how this will affect the extensions
Thanks
To add to what I said above ( https://github.com/Microsoft/vscode/issues/396#issuecomment-270326917 ), I actually do use Git submodules, so when I am working on my own (private) packages, it makes perfect sense to bundle them up, but since Julia is still fairly young (relatively speaking), I often need to do work on other packages alongside my own. I do not feel a compelling reason to add these other packages as submodules (although I could).
Generally, for Julia package development, I am constantly hopping across packages so having multiple project folders would be great :+1:
PS: MS, please pay more attention to Julia ;)
Simplest use case: microservices
Haha. Yes @saada 👍 It was actually microservices that brought us to VS Code. We are using Azure Service Fabric and my partner built the first microservices in .NET and Rust. I'm working on the Julia microservices. My partner is a VS guy and liked VS Code for Rust. He suggested I try VS Code for Julia. Thanks!
@saada definitely on the radar. Can you answer these questions to help me be crisper on the requirements?
- Is each microservice separated into its own git repository? Why or why not?
@waderyan one possible reason is that some popular PaaS platforms such as Heroku require each app (microservice) to be in a separate Git repo. Deploy-via-git-push has become a popular strategy.
@waderyan I signed up for a slot tomorrow & looking forward to it - but along the lines of use cases like this, ours is similar.
We are a large organization, we have a private npm registry, and publish our own modules that are shared within the organization. We have a react app with a client codebase that's a big app that consumes some common modules (like utility libs, shared components), and a server codebase that's comprised of several modules as well (express server app, backend data service components consumed by the service layer, and the actual services exposed to the client). Active development involves a minimum of two (the client and services layer) but troubleshooting can easily involve a half-dozen modules.
Even when using public npm modules, it is occasionally useful to have its source code linked directly and open in a separate VS Code instance to troubleshoot a difficult problem, or even a bug in a 3rd party module, but mostly it's our own code.
Each are separate git repos. There's no problem keeping them in my file system under a single root folder (i would anyway). But I need to have a separate instance of VS Code open for each one, and switching back and forth is painful because you can only see the file name - not the name of the application itself. There's no way to easily figure out which application/module/project is open in which window. The file name itself provides very little useful information in discriminating between multilple VS Code instances.
There's another open issue related to allowing the title bar information to be configurable which I have also commented on a lot - and also remains unsolved. If it were possible to have the root folder name flush-left in the title bar, the problem of having multiple projects open would be far less of an issue, because I could at least see which open instance was which within Windows when switching tasks. This seems like it ought to be really trivial to make configurable and would at least alleviate the pain of not being able to open multiple git repos in a single instance a great deal while this gets figured out...
@waderyan
My web projects are managed by a single parent folder. It's set up this way for organization, and quick links for my repository folders. I also do this, as it's easy for me to swap into a previous/current project to pull code samples when they are going to be reused. As opposed to opening another window, it's easier to open another tab, and more time efficient in my case.
Each web project has their own git integration, however for me personally, I don't require .git to be integrated into my code editor. It's a nice option for me, but not a requirement. They have their own .git integration due to wanting to keep each web project separate in my repo host.
@nickmak @jamietre @pesho thank you for sharing your thoughts. This is helpful and I'm looking forward to chatting with many of you more tomorrow.
@alefragnani I'm focused on the end user scenario. We've approached this issue cautiously because of the impact on extensions. We will tread carefully and communicate any api changes. Ping me on Twitter if you want and we can jump on a call to discuss more.
even notepad++ support multi folders. it's the reason cannot left notepad++. this day working with javascript needs to open multi projects.
I do embedded software work and there are usually a few folders I'm working out of across the system. For example application code, vendor library, and operating system code.
I would like to add my use case here for multiple folders in the same window.
I am a game developer and, for our current game, we have implemented mod support. Our game has a client, server and master server projects. Whilst editing the mod files it's common to only work in the mod level of the game (instead of what we call the core or native level of the actual game code. e.g. Working only in the Lua files instead of C++ and C# files for server and client respectively). The folders can often be not located within a common parent folder.
In this use case, when only working within the mod files, in the past we have used Sublime's multifolder functionality to create a project view of only the top level mod folders from the Client and Server. This allows us to avoid the native files (C# and C++) and quickly edit Lua files across those two projects that are very much related to each other.
Having multifolder support in VSCode would allow us to do the same and greatly ease our adoption of VSCode (which we love very much).
What came of the call that was held last week? I'm on mac and can't seem to open multiple instances of VSCode, which I thought would be a workaround.
thanks!
I had a call last week with Wade, it's obvious and fair that this wasn't a early priority, they've built a really good editor, and now hopefully they're extending it to meet different developer's needs. The Dev team are listening, I'm looking forward to seeing how they go about it
On Sun, 15 Jan 2017 21:20 nowherenearithaca, notifications@github.com wrote:
What came of the call that was held last week? I'm on mac and can't seem to open multiple instances of VSCode, which I thought would be a workaround.
thanks!
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode/issues/396#issuecomment-272724576, or mute the thread https://github.com/notifications/unsubscribe-auth/AA16yEIdTFJAnqXHLs_WUvrGBIR9G7f-ks5rSo2DgaJpZM4Gm3nX .
in great request mark
@nowherenearithaca I had great calls with a number of users and shared what I learned with the rest of the team. We're still figuring out next steps but I would expect we would do something in this area very soon.
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.