vscode 🚀 - 添加对在同一窗口中打开多个项目文件夹的支持

同意，但这也许是内存的优化解决方案

i5ting 于 2015-11-21

👎61 👍58 🎉4 😄2 😕1

+1

yoorek 于 2015-11-21

👍61 👎54

我不确定我是否明白这个要求；它是一个轻量级的代码编辑器，而不是IDE ...为什么您需要打开多个非分层的“项目”文件夹（您可以在其中将工作路径设置为共同的父级）？

如果您正在处理分散存储在磁盘上的模块，它们之间以某种方式相互交互，那么它们之间的关系就太紧密了，以至于...您的项目是兄弟吗？如果是这样，只要打开“解决方案”根目录所在的父文件夹或父/父文件夹...即可。

dmccaffery 于 2015-11-22

👎539 👍27 😕18 😄9 🎉3

好吧，如果您有许多彼此独立的模块（它们全部位于各自的git存储库中），但是您有一个使用这些依赖关系的存储库，则可以打开这些独立的文件夹并进行更改反映出来，以便您可以在本地进行测试。那仍然是一个轻量级的代码编辑器，但是更有用的一个恕我直言！

stoffeastrom 于 2015-11-22

👍195 😄1 👎1

将项目设置为父项的主要问题是git集成消失了，除了拥有共同的父项之外，还有其他有效的用例。

Tyriar 于 2015-11-22

👍71 👎3

@stoffeastrom听起来像是子模块的用例；我不确定您的项目将如何引用另一个项目，除非您使用某种机制（例如npm链接等）作为别名。这个问题是程序包管理器主要要解决的问题。如果模块紧密耦合，那么它们实际上不是隔离模块。您将无法可靠地进行更改以支持一个项目，而不必担心更改会给其他用户带来后果。正是由于这个原因，即使对于子模块，它们在默认情况下也是只读的。

无论如何， @ Tyriar刚才提到的是我很警惕在单个实例/窗口中使用这种多工作路径接口的原因之一：您必须处理集成（例如git），扩展，重构，调试，等等，等等，等等。例如：

如果我使用git集成来提交，我是在提交项目A还是在提交项目B？
如果我在TypeScript中重构了一个类名，那么它应该在项目A或项目B中，还是在两者中都重构？如果两个项目中存在相同的类名称且含义不同，该怎么办？如果一个人松散地引用另一个人怎么办？

这些只是看似简单的事情如何变得非常复杂，很快的例子。我认为这比在几个单独的VSCode实例之间使用alt-tab / cmd + tab来使人更困惑，而且没有那么有用，每个实例都可以愉快地管理自己的隔离工作路径，而无需所有额外的工作和边缘案例问题。

我并不是说无法解决问题，但是我不太明白为什么要在多个窗口和/或实例之间切换是一个问题。也许我在想什么...

dmccaffery 于 2015-11-22

👎101 👍13 ❤3 😕3 😄1

Sublime，Atom，Webstorm-它们也是“轻量级”代码编辑器（也许Webstorm除外），它们允许从不同位置打开多个根文件夹。这些编辑器可能占Web开发人员使用量的99％。
代码可以通过更好的Typescript支持与它们竞争（考虑到Angular 2将会流行），但前提是它可以为开发人员提供他们现在使用的基本功能。

yoorek 于 2015-11-22

👍374 ❤32 🎉12 😄9 👎1

+1

daniel-uzunu 于 2015-11-22

👎62 👍19 😕1

+1

nilzona 于 2015-12-02

👎60 👍20 😕1

作为Go开发人员，我发现此功能在Sublime或IntelliJ Idea中非常有用。例如，我的小项目从Go核心库中导入代码，或者可能会导入一些第三方库。因此，我需要能够快速导航到他们并阅读该代码。

elgris 于 2016-01-03

👍88 ❤5 🎉4 😕1 😄1 👎1

+1。现在，在VS Code中，多git回购微服务解决方案非常痛苦，正考虑寻找另一个具有Typescript功能的IDE。

rezonant 于 2016-02-28

👍51

我们绝对需要某种“解决方案”。我是一名本地开发人员，这几乎总是涉及构建一组libs / dll，然后从某个主机应用程序项目中引用它们。
一旦我们有多个项目，当我们按“运行”时，我们还需要一个“启动项目”。

TurkeyMan 于 2016-03-08

👍11

我还希望支持项目和多个git根。我经常使用的代码可以在几个git repos中找到，并且无法在不关闭我的当前工作区并打开另一个工作区以关闭并打开另一个工作区的情况下在它们之间进行切换，这很累人。如果我将所有资料库都存放在其父文件夹中，则可以在文件中进行导航和搜索，但会丢失git集成。这真是个无赖。

“文本编辑器”和“ IDE”之间的界线模糊不清，我并不在乎VS Code被标记为什么。我关心的是工具可以做什么以及使用起来多么轻松。我认为增加项目支持将减轻像我这样的人的摩擦。

Loren-Johnson 于 2016-04-21

👍20

当您的工作空间包含多个存储库时，我还希望看到git集成工作，但是我只是想确保像@ Loren-Johnson这样的人意识到他们可以同时打开多个vs代码窗口。

这是由于：“无法在不关闭当前工作空间的情况下在它们之间切换”

rhbecker 于 2016-04-21

您的意思是＃2686是否与此重复？

stoffeastrom 于 2016-04-27

抱歉，我误读了说明，然后重新打开了该说明。

bpasero 于 2016-04-27

👍4

+1

Sapunov 于 2016-05-19

👎31 👍3

在此问题上是否有任何进展，或者至少会发表一些声明（如果可以实施）？代码中是否存在一些低级决策，这些决策会阻止一个项目中出现多个根？

这几乎是我不打算从ST3转到VSCode的唯一原因。

lepinkainen 于 2016-05-31

👍65

+1

jolav 于 2016-06-28

👎44 👍6

+1

josebalius 于 2016-06-29

👎45 👍3

+1

mibanez 于 2016-07-04

👎45 👍4

+1这将非常有帮助。使用git子模块的建议非常不便。很想拥有这个功能。

matthewatabet 于 2016-07-06

👍3 👎1

最初的轻量级方法将类似于git-project-manager扩展。该方法可能是基本上将git视为更改的上下文/根目录切换，而不更改文件浏览器所看到的上下文/根目录。此扩展工作完美，只需要更紧密的集成即可加快切换速度。

kalinkrustev 于 2016-07-06

👍3

+1

xcorpio 于 2016-07-07

👎46 👍3

+1-我开始尝试使用git子模块，但感觉比实际解决方案更像是一种hack。

shoerob 于 2016-07-07

+1

anidexlu 于 2016-07-08

👎46 👍2

+1

mdedgjonaj 于 2016-07-09

👎45 👍3

我正在使用git-project-manager扩展名在文件夹之间切换，但是我真的很想有一个选项可以一次打开多个文件夹。
+1

rampage644 于 2016-07-12

👍3

只是想说Project Manager扩展的所有者也正在等待此问题。

关于上面的一些评论，我只想说我们都是不同的，我们都有特定的方式来执行特定项目的工作。这个事实使UX比现在更加重要。

我们都知道，“打开文件夹...”只是在诸如“打开项目...”之类的vscode中不可避免地进行项目管理的第一步。就像那里的所有其他编辑器一样，尤其是SublimeText（我来自那里）。

对我来说，此问题是对产品UX的改进。我们都知道UX为王。

我几乎觉得这种东西应该是法律，因此标签“功能请求”应该改为“功能提醒”。

此问题应该比vscode中的任何其他问题具有最高优先级。不仅是因为UX为王，而且因为除了这个问题之外，我现在还没有遇到过vscode的任何其他问题。

我最初是在浏览，要求微软仅接管这些类似于项目的扩展并将其直接集成到VSCode中，并改善其UX，例如，通过在菜单中添加“ Projects ...”。

谢谢，
+1

ryanbriscall 于 2016-07-12

👍54 🎉8 👎2

+1

elirenato 于 2016-07-15

👎36 👍2

我对此功能的用例在这里描述：＃9515。（已关闭，作为此问题的重复。）

donaldpipowitch 于 2016-07-20

我希望此功能能够实现！

mastrauckas 于 2016-07-25

👍19 👎10

+1

poidl 于 2016-07-30

👎34 👍3 😄1

@ poidl，@ mastrauckas ，@mdedgjonaj，@alanleite，@Xcorpio，@mibanez，@josebalius＆@brusbilis：
不久前，GitHub引入了可爱的“添加您的反应”功能（查看评论右上角的笑脸还是问题本身？）。
这些目的是为了使VSCode团队了解您的兴趣，但可以防止毫无意义的+1评论。它还可以防止其他订阅某个问题或MR的人获得通知，从而节省宝贵的时间。另一个好处是，可以通过most reaction对问题/ MR进行排序，这使VSCode团队可以立即看到与用户相关的内容。最重要的是，甚至还有VSCode的Uservoice 。

此评论本身是元信息，因此也没有任何意义。对此我感到抱歉，但我认为这对于教育目的是必要的。对此评论的每次直接回复（=更多元）都会导致我屏蔽该用户。
让我们通过仅使用reaction功能对此评论做出反应来进行练习！

致@poidl的回答：那根本不要回答！

crunchtime-ali 于 2016-07-30

👍33 👎4 ❤2 😄1

我没有看到那个笑脸。至少在手机上。封锁愉快！

poidl 于 2016-07-30

👎29 😕3

@poidl是，

@ dj-hedgehog的建议很明显，GitHub的反应使我们能够比评论数量更有效地衡量社区对某些事情的兴趣。此外，我们正计划弃用用户语音，因此GitHub问题和响应是我们提出功能要求的真实来源。

Tyriar 于 2016-08-01

👍7

+1

sunyuu 于 2016-08-03

👎48

+1

ejmarino 于 2016-08-03

👎50

我对这个问题的解决方案：创建到我的项目根目录的符号链接。
所以，如果我有：
project/modules/gitmodule

我进入gitmodule文件夹并执行以下操作：
ln -s ../../../project .project

现在，我可以在vscode中打开我的gitmodule文件夹，并且仍然可以访问父项目文件夹。
我在文件名中使用了一个点，因此它在资源管理器中排在我列表的顶部。
显然，我宁愿不必这样做，但我认为它对某些人可能有用。

差点忘了：不要忘记将符号链接添加到您的.gitignore

jimmynavio 于 2016-08-05

👍12 👎3

+1

Gee19 于 2016-08-05

👎30

对于现代文本编辑器来说，这是一个非常重要的功能。请解决这个“问题”。
有一阵子，我不得不将所有目录复制并粘贴到我的实际工作文件夹中，而Sublime Text中的目录是如此的琐碎。

“项目”>“在Sublime Text处将文件夹添加到项目中”会增加Json结构的新路径。

看下面：
{ "folders": [ { "path": "~/cpp" }, { "path": "~/python" } ] }

arthurhenrique 于 2016-08-05

👍19

例如，当与Chef一起工作时，通常会看到如下文件夹结构：

└── cookbooks
    ├── cookbook1
    ├── cookbook2
    ├── cookbook3
    └── cookbook4

根文件夹（cookbooks）下的食谱（例如，cookbook1）是独立的git repos。这很常见。现在，您必须处理cookbook4，但其中包括cookbook2和cookbook3。您经常需要打开所有3个代码，以简单地引用代码，或者在所有3个代码中实际编辑或重构代码。

2个普通（不是symlink hacks）选项提出了开发人员不希望遇到的问题：

如前所述，您现在必须打开多个窗口（不好）
如果您以root用户身份打开cookbooks来查看全部3个，则由于cookbooks文件夹不是存储库（同样不好），您将失去git集成

dadreggors 于 2016-08-18

👍16

+1，这里的Eclipse IDE用户具有完整的“工作区”控制功能。

danielsokolowski 于 2016-08-20

Visual Studio Code不是IDE。它是轻量级的跨平台编辑器，例如Atom或Sublime。 Eclipse，Xcode，Visual Studio等。相比之下，它们都是庞然大物。

dmccaffery 于 2016-08-20

👎71 😕29

抱歉，我不确定您是反对还是为此功能辩护... Atom，Sublime，VIM，Emacs允许您在一个实例中打开多个文件夹。是否轻便是一个好功能，例如IntelliJ IDEA（一种IDE）不允许您仍然打开多个项目。

danielsokolowski 于 2016-08-20

😄12 👍10

@dmccaffery这里要求的功能不只是IDE功能，要求的功能对于您所说的Visual Studio Code是_like_的所有_editors_都是通用的。

Atom，Sublime和其他轻量级编辑器都可以打开多个文件夹。

dadreggors 于 2016-08-20

👍21

我个人并不关心此功能是否会出现在产品中-我理解为什么有些人想要它，但是我要指出的是，它确实使所有内容变得更加复杂。例如：使用正则表达式进行搜索时-我要搜索哪个工作区？一？所有？

如果我有一个文件夹包含一个nodejs项目，其中选项卡宽度通常为2个空格，而一个文件夹是一个dotnet项目，其中我的选项卡宽度为4个空格，怎么办？代码需要注意每个文件夹的工作区设置，并始终保持上下文。

这些仅是几个示例，这些示例说明在单个实例中可能很难实现多个工作空间的情况。我要说的是，此功能比在浏览器中显示多个路径要复杂得多。

dmccaffery 于 2016-08-20

👎62 👍2

@dmccaffery比崇高和原子更令人费解。这应该都是可配置的，甚至每个工作空间选项卡的宽度也是如此。在atom和sublime中搜索只能在当前文件中，在此工作空间中等等，这是您的选择。

这是一个事实，无论您是否喜欢，都与您或我想要的无关。如果价格相近的其他类似软件（在这种情况下免费）具有更好或更多的功能，而开发人员忽略了这一事实，则该软件将被抛在后面。

我不想让这种编辑器发生这种情况。我认为该编辑器具有很大的潜力，并且可以在一段时间内保持相关性-如果开发人员听取了其用户群的需求。

dadreggors 于 2016-08-20

👍14

再次; 我并不是在反对或反对-只是要记住，这是一个非常新的编辑器，其上下文比其竞争对手要多得多-给它一些时间。

即使在带有Chef和git集成的示例中，您如何维护提交给哪个仓库的上下文？当前的UI需要适应恒定的上下文切换-对于OmniSharp而言，情况相同，后者使用服务器和roslyn为CoreCLR项目提供语法突出显示等。其影响是深远的，需要进行深思熟虑。

dmccaffery 于 2016-08-20

👎23 👍5

对于功能需要精心计划和考虑的想法没有争议。那是我想的。我认为，如果这里的答案是“正在制定路线图”或“我们正在为此努力”，那么所有用户都会很高兴。我要说的是，“不”可能会在一夜之间杀死大量用户。

关于厨师中的上下文切换和git repos，是的，这是正确的，并且在其他开源编辑器中已经完成。您知道开源的伟大之处在于，它是开放的！查看代码，获取想法，甚至使用其中的一些代码（确保根据需要包括许可）。这是关于foss（免费开源软件），协作和知识共享的伟大事物之一。由于该编辑器已经在使用原子代码...我想这也是必须的。

dadreggors 于 2016-08-20

👍5

我发现在https://github.com/Microsoft/vscode/wiki/Roadmap中提到了这一点

VS Code是一个年轻的产品，仍然缺少您要求和我们想要提供的功能和体验。
....
....
一个工作区中有多个文件夹

我认为没有人会说此功能很简单（因为我们所有人都是开发人员，我们可以知道需要更改的地方），我邀请人们对此票发表评论只是想表明它的重要性，优先级，以及如何将此功能与某些VS Code兄弟（例如Atom，Sublime）进行比较。

但是因为这已经在路线图中（任何人都可以确认Wiki页面仍然正确），我们应该讨论如何实现此目标，而不是仅仅说明我们的需求和重要性（再次，我猜想VS Code核心团队已经知道我们如何需要它以及此功能的重要性）。

我不熟悉VS Code源代码，是否有人可以告诉我是否要实现此功能，我应该首先看哪里？第一步，我只想打开多个文件夹并将其显示在左侧栏中。

nvcnvn 于 2016-08-22

👍15

@nvcnvn它并不像实现它看起来那么琐碎，因为许多vscode假定只能打开一个文件夹。因此，它将需要遍历UX，并可能涉及代码库的许多部分，这也可能会影响扩展API。

Tyriar 于 2016-08-23

👍6

我记得Atom推出时具有相同的_single folder_限制。抱怨也一样，特别是与Sublime的比较。然后，当_multiple folder_支持被释放时，由于新的API，一些软件包（扩展名）被破坏了。其他人没有破产，但也没有支持它。它花了一些时间才在整个生态系统中变得稳定。

正如@Tyriar所说，这将对UX和扩展API产生影响，并且对于核心和扩展开发人员来说，采用新的API可能是一个忙碌的_Insider_版本。

alefragnani 于 2016-08-23

👍6

那么这里到底在争论什么呢？
我的意思是我所看到的只是“不要进行改进，因为它可能会破坏事情”。

暗示：
代码中的所有改进都可能会破坏某些功能！

这就是调试，重构，预发布（alpha，beta，rc等）的关键所在。
来吧，认真吗？我从未见过一个认真的程序员，他害怕改进代码，因为它可能会破坏某些东西。是的，要谨慎，花点时间，要安全，是的，但不要说“不，它可能会破坏事情”

dadreggors 于 2016-08-23

👍20 😄5 ❤4 👎3

@ddreggors我没有争论，我只是在说一些有关此问题的信息。我说了我要说的话，是为了避免@nvcnvn尝试为此构建PR，因为由于涉众的列表，这需要团队进行。

作为@nvcnvn指出，这个问题是在发展蓝图意味着球队将在很快寻找。我们是一个相对较小的团队，但是有很多工作要做，因此有些事情需要延迟。

Tyriar 于 2016-08-23

👍7

@Tyriar理解，我只是不断地从几个人那里看到这些评论，这些评论似乎暗示最好不要出于一个或另一个原因添加此功能。最糟糕的情况是由于代码不是IDE，而其他人显然将其他编辑器而不是IDE进行了比较。它使我想对这种变化的恐惧根源，如果可能的话，克服它。

我可以理解PR不够完整的担心，但是这可能是一个不错的开始……将更改合并到一个分支中并将其用作基础。使用它可以查看破损并进行修复。

dadreggors 于 2016-08-23

❤1 👍1

@ddreggors ，在我们的一次UX会议中讨论该问题之前，任何人都将浪费精力进行触摸

Tyriar 于 2016-08-23

公平地说，您最了解这一点。很高兴知道正在对此进行讨论。 :-)

感谢您的努力，这是一个非常好的编辑器的开始。

dadreggors 于 2016-08-23

❤2 👍1

在您的UX会议上建议这个主题似乎也浪费了精力：

我暂时切换回Atom，因为它在1.9版本中变得更加稳定。它曾经在打开任何大文件时崩溃，这是在某个时候开始签出VSCode的主要原因。真的很期待在一个窗口中看到多个项目–似乎我无所事事，但直到那时我都遵循此线程。

kachkaev 于 2016-08-23

👍4

为什么微软人不专心呢？

pixelbyaj 于 2016-09-05

👎2 👍1

+1

mulianju 于 2016-09-07

👎20

+1

elvestar 于 2016-09-09

👎21 😕2

我真的很喜欢VS Code。它已经成为我的主要编辑，但是同时处理两个以上项目的困难变得令人困惑。在这两个未解决的问题上存在双重打击：这个问题和配置标题栏信息。

这些功能中的任何一个都可以解决问题（尽管理想情况下，我希望两者都可以！）。我不介意将要处理的所有内容放在单个文件夹中并打开它-但是git集成不起作用，并且没有简单的方法可以在一个项目中进行搜索或按项目组织结果。

我不介意在不同的物理VS Code窗口中打开每个项目，并让我的OS管理实例-但由于标题栏首先显示了打开的文件名，而不是某些根文件夹/项目标识符，因此无法切换到另一个特定的打开项目，而无需打开并查看每个活动实例。它使一些本来应该毫不费力地变成不断烦恼的事情。

请-有什么办法可以使这两项功能之一成为优先事项？我已经尝试了所有可以解决的问题，甚至花了一个小时寻找一些Windows任务栏替代方案，该方案可以让我从列表中选择可以在标题栏中显示更多文本的窗口，但我找不到任何东西。

如果有人对如何有效地管理多个VS Code开放项目有任何建议，我希望听到他们的建议。

jamietre 于 2016-09-09

👍4 ❤1

在Atom中运行良好的重要事情是，诸如eslint之类的插件仍应在项目级别运行。因此，如果项目A有自己的陪同规则，则项目B不应受到这些规则的影响，反之亦然。等不及要在代码中拥有这样的UX。如果不是目前最大的采用障碍，那么这绝对是其中之一。

saada 于 2016-09-11

👍4

这是唯一让我接受的东西。

我知道您可能还有很多其他问题需要解决，还需要实现其他功能，但是至少有一些基本的入门支持非常不错。

感谢您对VSCode的辛勤工作！

douglas 于 2016-09-14

👍17

+1

mrlami 于 2016-09-15

👎13 😕1 👍1

在实现此功能之前（如果有的话），我是否可以建议您简单地添加配置标题栏以在文件名之前显示项目名的功能。这样，至少可以区分为不同项目打开的不同vscode窗口。参见＃1723 。

gilboa23 于 2016-09-17

👍5

对我来说，这也是一个表演的障碍。我看到一些开发人员想知道为什么您一次拥有多个git repos。几乎所有使用第三方模块的语言都会发生这种情况。只需看一下php-composer，js-bower，node-npm，golang等。启动一个使用某些模块的项目是很常见的，并且您想要编辑并提交项目范围内的更改。

nkostadinov 于 2016-09-19

是否至少支持在嵌套目录中识别.vscode/settings.json 。当处理单个项目时，可能会有带有不同设置集的子树，这些子树来自不同的（git）存储库。例如

root/
    server/
        .vscode/
            settings.json // <== affects all files in the server/ directory
        code/
            tsconfig.json
            foo.ts
    client/
        .vscode/
            settings.json // <== affects all files in the client/ directory
        code/
            tsconfig.json
            foo.ts
    .vscode/
        settings.json // for any file not in server/ or client/

我希望vscode可以像许多配置文件一样接受（并合并）最近的父目录的设置（ .eslint ， .gitignore ， .editorconfig ， tsconfig.json ，'package.json` ....）。

因此，当我打开/root ，应该处理root/server/任何文件，就像我直接打开root/server/ 。最简单的解决方案是停止在父目录中搜索.vscode/settings.json文件中的设置。

scharf 于 2016-09-19

👍7

这确实是需要的。

KioriSun 于 2016-09-23

👎5 👍2

+1。给我带来破坏力。

joerx 于 2016-09-25

👎7

这确实是需要的。 +1

jeffery9 于 2016-09-25

👎9 👍3

有一种解决方法可将文件夹嵌套在vscode工作空间下。只是创建一个指向工作空间文件夹的符号链接，像这样的mklink /d link target

jeffery9 于 2016-09-25

🎉3

我同意-我认为这个要求是明确的要求。
您并不总是在单个文件夹中有一个项目-您可以有辅助文件夹和同级文件夹，而就目前而言，不具有此功能确实是一个大问题-这就是为什么我必须使用sublime。
请添加！

ghost 于 2016-09-28

👍1

在左侧，显示您作为项目所在的文件夹。如果您可以在其中看到每个文件夹区域（项目）在此打开的地方，则可以使用此方法。您可以像现在一样展开和折叠它（但对于多个文件夹区域）。

soljohnston777 于 2016-10-04

一个很棒的编辑器，如果我能在两个项目之间切换的话。一个真正的破坏者。

enyachoke 于 2016-10-10

👍2

大家好，如果您同时在项目之间进行大量切换，我建议使用Git Project Manager扩展。它扫描目录中包含.git文件夹的目录，并允许快速切换到它们，我已经使用了几周，它的确使它变得更加容易。

当我切换项目时，我要么去：

Ctrl + Alt + P
输入项目开始，例如。 vscode的“ vsc”
输入

或者，如果我想在另一个窗口中打开项目，请先按ctrl + shift + n 。您也可以将扩展程序配置为始终在新窗口中打开。

Tyriar 于 2016-10-10

👍3

untitled-1

这是有关如何轻松拥有多个项目的屏幕截图。

soljohnston777 于 2016-10-17

👍2 👎1

@ soljohnston777问题是文件夹级别不支持git集成（或任何其他种类的VS代码配置）。

jamietre 于 2016-10-17

问题是文件夹级别不支持git集成（或任何其他类型的VS代码配置）。

真的吗？ VSCode是否重复了有关工作区概念的日食错误？知道VSCode团队的很多成员已经成为eclipse核心团队的一部分，这真是令人惊讶。

scharf 于 2016-10-18

VSCode是否重复了关于工作区概念的日食错误

我不能在这里谈论架构师的理念，但是这个事实（配置是针对每个实例而不是针对每个文件夹）是导致此问题和讨论的全部原因。

jamietre 于 2016-10-18

您可以将单独的VScode窗口用于项目。为什么不像在VSCode中那样实现它（每个侧面项目按钮都有单独的窗口-只需在内部引用它）。这样可以省去在程序内部进行编码的麻烦，而项目却在内部显示，并且易于集成和开发。

可以为多个项目的每个文件夹区域单独放置Git ...我发现git与VSCode混淆了，所以无论如何我总是只做命令行（看来您应该可以在VSCode中做到这一点）。

soljohnston777 于 2016-10-18

当父文件夹包含独立的git存储库的子文件夹时，当它们都属于同一项目时，这确实很有帮助。希望看到此设置，至少在设置中带有可选的配置标志。

aga5tya 于 2016-10-18

我还想表达我对具有多个git repos的git支持的浓厚兴趣。

philicious 于 2016-10-19

👍1

+1。这是一个主要功能，阻止了我将VSCode用作主编辑器。

doughywilson 于 2016-10-21

👍16

+1

kennethtaylor 于 2016-10-21

👎13 😕2 👍1

+1-特别是对于使用微服务/许多存储库代码的人来说，这是关键。（关键：不要一次打开所有文件，而是在它们之间进行切换，并让编辑器记住哪些文件是打开的以及在哪些工作区中。）

d-sparks 于 2016-10-22

+1
我们的设置类似于GIT存储库中的核心代码，另一个存储库中的某些区域代码，以及另一个存储库中的项目特定代码，因此，当您处理项目时，需要从所有三个（或更多）存储库中进行编码。不能通过自己的特定设置来创建“项目”，并且无法从多个来源添加多个文件夹，这是阻止程序的王者。

danechitoaie 于 2016-10-24

@danechitoaie您如何知道对核心存储库所做的更改不会破坏依赖于其他区域或项目代码库的其他人？似乎是一种危险的工作方式；应该使用某种程序包管理系统或类似程序进行单独的发布管理。

并不反对某些工作空间的实现，但是成熟的项目系统会增加相当多的复杂性。

dmccaffery 于 2016-10-24

同意，是的，他们应该/可以做很多更好的事情，但是...这超出了我们的“最终用户”控制或做出决定的能力...

danechitoaie 于 2016-10-24

😕1

明白了当这种事情发生时，我喜欢它。

dmccaffery 于 2016-10-24

b2r1ifriyaa-bnh
这个怎么样？

min20 于 2016-10-25

👍19

对我来说，像这样简单的开关按钮还不够。如果我们只需要打开2个实例（Ctrl N键），那么使用OS热键在Windows /工作区之间切换就差不多了。
我喜欢拥有使比较文件，项目结构更容易的工具，可以帮助我快速进行较小的更改，并在同一屏幕上生成并保留所有差异，从而能够还原正在处理的所有项目的更改。

nvcnvn 于 2016-10-25

👍5

+1

mkszepp 于 2016-11-05

👎11

+1

macOS Sierra的一种解决方法。

通过在停靠设置中将Prefer tabs when opening documents为Always ，可以在一个窗口中为每个项目使用一个标签。但这也会影响其他应用程序的行为。

Fenkiou 于 2016-11-06

+1

williamokano 于 2016-11-11

👎12

这正成为我的杀手.。我喜欢这个程序，但是我不喜欢只有一个窗口的人...

nucleardreamer 于 2016-11-11

老实说，我不得不停止使用Code，因为就我而言，它变得太麻烦了，无法切换窗口。

如果以后解决此问题，我将再次尝试，直到那时为止，这对我和我所测试过的每个人都是一个秀场停止者。

dadreggors 于 2016-11-11

+1

hugobessa 于 2016-11-14

👎11

+1

dbkaplun 于 2016-11-14

👎13

请更喜欢：+1：对原始问题的评论，因为这有助于我们进行优先级排序，并且不会将通知发送给每个听该问题的人以进行更新。

Tyriar 于 2016-11-14

👍15 😄1

+1

我目前正在使用Sublime，并尝试使用Code。看起来和感觉都不错，但是单个项目Git集成却是一个大问题。我有一个Hadoop / Oozie项目，因此有一个代码库和另一个工作说明。在Sublime中，我将它们都在同一窗口中打开，并且可以为每个窗口提交适当的Git存储库

因此，添加它会很好

riotgibbon 于 2016-11-16

+1是，在微服务领域很关键，通常同时打开3..4仓库

kristok 于 2016-11-16

每周提醒：停止以+1发表评论。 取而代之的是竖起大拇指，这实际上是很重要的。

我知道你们都很好。因此，请随时删除您的+1评论，以免占用此重要历史记录的空间！

jamietre 于 2016-11-18

👍12

@jamietre我已经尝试过...努力：

screen shot 2016-11-18 at 6 28 16 am

dmccaffery 于 2016-11-18

👎3 👍3

也许另一种选择是锁定此问题，但保持打开状态直到解决？这样，我们知道了问题的重要性（我想我们已经为它提供了足够的+1），但不能增加混乱/冗余（例如，不允许再发表评论）。

虽然这是我认为很少使用的功能，但我只遇到了Github上一个公共项目/仓库的锁定。

如果认为有必要，可以解除锁定。

daluu 于 2016-11-18

👍2

@daluu这是/ aspnet / announcement存储库的工作方式；每个问题都将立即锁定。话虽如此，GitHub应该在用户界面中做一些事情，以至少促使人们朝着除了“ +1”之外的替代方案发展，因为现在存在反应。 👍

dmccaffery 于 2016-11-18

把多窗口这个功能整上把，看两个项目以上的文档时，很有帮助，

GameMidlet 于 2016-11-23

👎11 😄2

解决问题的有趣方法。我曾担任VB / .net程序员多年，喜欢这些语言和工具，但是在Hadoop / Spark / Scala / Intellij / Sublime-land离开了几年。我仍在听DotNetRocks，喜欢跟上最新动态，并有兴趣了解此Code应用程序。从积极的方面来看，它是一个非常不错的编辑器，具有一些不错的Git功能，但是不幸的是，这完全无关紧要。因为它不能像Sublime那样优雅地处理同一工作区中的多个项目的Git，所以我无法使用它

那个会发生。我最惊讶的是这里的反应，首先声称这不是必需的功能，然后现在大多数讨论都围绕“我们如何阻止人们发布+1”

我将告诉您您的操作方法-您可以解决一年前提出的一个基本问题！这就是“听反馈”。仅仅因为您自己不受问题影响，并不表示它不存在。如果您不希望特定的用户组使用该应用程序，那就很好，但不要给我们提供反馈机制，然后对我们的问题提出异议，然后因为不断要求它而使我们烦恼。

我回到使用Sublime

riotgibbon 于 2016-11-23

👎1 👍1

可以用以下代码解决“ +1”问题：if（post_message ==“ +1”）{add_smiley_reaction（）; delete_post_message（）; }

亲爱的GitHub，我可供出租。

K280R900 于 2016-11-23

😄11 🎉1

是的，这永远不会解决，是吧。嘲笑和忽略“ +1”注释比实际解决核心问题要容易得多，软件是针对开发人员的特定部分销售的，这些软件并不能满足他们提高生产力的需要...

只需阅读此文章“对此评论的每次直接回复（=更多元）都会导致我屏蔽用户。” -现在，这就是管理反馈的方法！用手指捂住耳朵，说“听不见！”

亲爱的主

riotgibbon 于 2016-11-23

@ kryps1，然后人们会添加“ +1”或“ ++ 1”或“ 1+”或“凹凸”或“是，请+1”。无论您做什么，人们都会找到解决方法。并不像您想的那么容易。

danechitoaie 于 2016-11-23

😄1 👍1

请停止对+1的无用辩论，请...在这里重点关注什么是资源管理器中的多个项目。

对于git问题，只需用资源管理器相同的方式进行拆分（即，通过cwd）。

soyuka 于 2016-11-23

👍4

让我们不要为+1引发一场火焰之战。如果将此问题放在优先位置，那肯定会很好。

但是，我想向社区提及，欢迎PR和贡献；-)如果核心开发人员不了解，则可以修补/修复代码。我的一些项目得到了改进（使用fork进行了改进），因为用户/开发人员宁愿自己做，也不愿等我做出他们想向我建议的改进。因此，任何对此问题感到恼火并且足够有能力/技能的人，都请解决（然后提交PR）？大声笑

回到+1主题，大胆地提出问题并添加您的意见是不错的选择，但如果还有其他方法（例如，竖起大拇指的功能），+ 1就是一种me脚的方式。考虑一下Facebook帖子或原始的Google+帖子，用户/读者可以添加+1评论，而不是单击Like（或Facebook的新反应之一），或单击Google+ +1。随着时间的流逝，这是一长串la脚的+1注释线程，当我阅读时，我可能正在滚动查看有趣的注释，但最终看到了一堆+1。这就是这里发生的情况，无论我是项目开发人员还是用户（或正在研究该项目以供潜在使用），我都不希望通过这些+1查看/阅读。

在相关说明中，这是对GH问题的愚蠢（但是出于善意）使用，感谢上帝，尽管如此，人们并没有全力以赴+1： https :

daluu 于 2016-11-23

我想欢迎PR和贡献

并不是的。请参阅八月份的评论： https :

显然，至少从那时起，该问题就一直存在于路线图中，但是目前尚无进展。很高兴听到VSCode团队的状态更新。

pesho 于 2016-11-23

👍3

对我而言，这正试图使主题重新回到正轨，因此需要多个项目文件夹。

在Atom中，它支持GIT，而我使用它的唯一方法是记录哪些文件已更改。我有一台不允许SSH的Rackspace服务器，所以我手动上传了。但是，我能够在边栏中拥有多个项目文件夹，这使得引用我在先前项目中使用的代码变得非常容易。如果我需要喘口气，或者将齿轮切换到另一个项目。

使用VSCode时，阻止我旋转的问题是我想切换的问题是，边栏中缺少多个项目文件夹。

我的意思是我想我可以打开根文件夹来临时解决它，但是如果我只需要3/20文件夹，而又不想看到松散的文件，那么这应该很容易实现，对吧？

kupoback 于 2016-11-25

更新：即将推出的大型工作台更新是热出口（＃101），在处理热出口时，我们一直在积极讨论此问题，以确保设计考虑多个文件夹。

当前，此问题在以下方面是

于：+1：评论；他们只会惹恼80多个订阅该刊物的人。但是，对问题进行表决是影响项目的最有力的措施之一。

还请记住，我们是一个相对较小的团队，代码库的清洁度和vscode的性能非常重要，因此需要花费一些时间才能正确地做。特别是对于像这样的东西（这是迄今为止对vscode的构建方式的根本改变）而言，在此问题上有很多工作要做。

Tyriar 于 2016-11-26

👍50 ❤7

+1

gioulisapo 于 2016-12-07

👎29 😕6 😄2

确实，这将是一个方便的功能。

aleonidis 于 2016-12-28

👎4

我从Atom切换到了，并且真的很喜欢它，但是我同时使用两个UI应用程序和另外两个SDK，但是缺少在这些项目（或文件夹）之间快速切换的能力是一个重要的不足，我想我应该回到Atom之前，解决了

Negan1911 于 2016-12-29

我真的很期待这个功能~~~

liupy525 于 2016-12-30

👎3

我是使用vscode的golang开发人员，希望它有一个工具，谢谢！

nolanjian 于 2017-01-02

👎3

我正在尝试从Sublime切换到VScode。不久，我发现VScode在“项目”概念中不支持多个文件夹确实是阻止我这样做的一个问题。

真的很喜欢这个“轻量级”编辑器的其他功能。同时，我相信在一个“项目”中支持多个文件夹不会使VScode变得“超重”或“类似IDE”。这将使使用其他编辑器的开发人员更加方便，从而使过渡的痛苦大大减轻。

希望能有所改善。谢谢！

kevinlinxp 于 2017-01-03

👍3

另外，如果团队可以添加保存基于项目的设置的功能，而该功能将覆盖默认设置，那将是很好的选择。用例是如果我可以为不同的项目使用不同的解释器。同样，具有不同的选项卡大小等也将有所帮助。请让我知道是否可以通过某种方式实现。

作为开发人员，我们始终致力于多个项目，并且拥有自己的副项目。每次切换项目时都自定义项目设置（vscode的工作区设置）是一件很麻烦的事。

bajubullet 于 2017-01-03

@bajubullet您应该尝试https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig不知道它是否涵盖了您需要的所有内容，但这只是一个开始。

danechitoaie 于 2017-01-03

👍2

@danechitoaie感谢您的回复。不过，EditorConfig并没有帮助，我可以为每种文件类型指定属性，但是如果我可以将它们保存为项目设置，则将更加容易，而且我不希望每个项目都具有.editorconfig。同样，对于像python扩展这样的扩展，我们让我们提供要使用的解释器，这将无济于事，因为editorconfig不支持python.pythonPath。如果我在这里缺少什么，请告诉我。任何建议都是最欢迎的。

bajubullet 于 2017-01-03

我同意，我也非常期待某种特定于项目的设置，并且能够打开多个“根”文件夹。这是我从Sublime唯一想念的东西。

danechitoaie 于 2017-01-03

这即将实施！

因此，无需继续添加此帖子。如果还有其他问题，请创建一个新线程。谢谢！

soljohnston777 于 2017-01-03

👍12 🎉11 😄1

这是一个很长的线程，我可能读了其中的三分之一，但只想表达我的支持。我刚刚用https://github.com/JuliaEditorSupport/julia-vscode安装了VS Code，以替代Atom / Juno。很美丽！ 😍

但是，在开发Julia代码时，我觉得能够在不同文件夹中打开多个包非常重要。原则上，我可以打开上面的文件夹，但这将暴露我安装的100个Julia软件包。我也可以更改LOAD_PATH，但我更希望使用VS Code解决方案。

我衷心希望能够打开多个文件夹。谢谢你的努力👍

EricForgy 于 2017-01-04

👎2

大家好，您可能已经注意到，我们正在此迭代过程中探索此问题的实现。

从https://github.com/Microsoft/vscode/issues/17608

调查跨不同组件的多根工作区@team

在我们仔细考虑实施细节时，我希望与您的3-5个人聊天。如果可以的话，请在下周二注册15分钟的时段。我想聊天。

waderyan 于 2017-01-06

👍7

在我的api和ui之间切换使我发疯... :-(

ehartford 于 2017-01-07

👎3

@ehartford有什么特别的原因，尤其是他们没有共同的父母吗？

Tyriar 于 2017-01-07

是。如果仅打开父目录，则Git集成将无法正常工作。

ehartford 于 2017-01-07

👍2

@ehartford很好的理由：微笑：

Tyriar 于 2017-01-08

@waderyan您是否只在寻找_end user_用例，还是在寻找_extension developers_？

作为_end user_，多文件夹支持在大多数情况下对于_searching_都是有用的。我曾经创建过Projects，它们从不同的API添加了不同的文件夹，只是为了使搜索更容易（统一）。我会说我今天不会错过那么多，并且今天也不会打扰我拥有多个VSCode窗口，尤其是在添加Switch Window命令之后：+1

作为_extension developer_，我有一些基于_Project Context_的扩展，例如context.workspaceState ， activationEvents/workspaceContains 。还有Project Manager ，顺便说一下，我已经开始重构内部结构以支持多文件夹。我很想知道这将如何影响扩展

谢谢

alefragnani 于 2017-01-08

为了补充我上面说的内容（https://github.com/Microsoft/vscode/issues/396#issuecomment-270326917），我实际上确实使用了Git子模块，因此当我在自己的（私有）包上工作时，它将它们捆绑在一起是很有意义的，但是由于Julia相对来说还很年轻（相对而言），所以我经常需要与自己的其他软件包一起工作。我没有理由将其他软件包添加为子模块（尽管可以）。

通常，对于Julia程序包开发，我经常在程序包之间跳来跳去，因此拥有多个项目文件夹会很不错：+1：

PS：MS，请多加注意Julia;）

EricForgy 于 2017-01-08

最简单的用例：微服务

saada 于 2017-01-08

❤5 👍2

哈哈。是@ saada👍实际上，微服务使我们进入了VS Code。我们正在使用Azure Service Fabric，我的合作伙伴在.NET和Rust中构建了第一个微服务。我正在研究Julia微服务。我的伙伴是VS专家，并且喜欢VS Code for Rust。他建议我尝试使用VS Code for Julia。谢谢！

EricForgy 于 2017-01-09

@saada肯定在雷达上。您能否回答这些问题，以帮助我更加精通要求？

您的微服务是否共享一个父文件夹？为什么或者为什么不？
每个微服务都被划分到其自己的git存储库中吗？为什么或者为什么不？

waderyan 于 2017-01-09

每个微服务都被划分到其自己的git存储库中吗？为什么或者为什么不？

@waderyan的一个可能原因是，某些流行的PaaS平台（例如Heroku）要求每个应用程序（微服务）必须位于单独的Git存储库中。通过git-push部署已成为一种流行的策略。

pesho 于 2017-01-09

@waderyan我明天注册了一个插槽并期待它-但是按照这样的用例来看，我们的情况是相似的。

我们是一个大型组织，我们有一个私有的npm注册表，并发布在组织内共享的我们自己的模块。我们有一个带有客户端代码库的react应用程序，该客户端代码库是一个消耗大量公共模块（例如实用程序库，共享组件）的大型应用程序，并且服务器代码库也包含多个模块（express服务器应用程序，服务层，以及向客户公开的实际服务）。主动开发至少涉及两个（客户端和服务层），但故障排除可以轻松地涉及六个模块。

即使在使用公共npm模块时，有时也可以直接将其源代码链接并在单独的VS Code实例中打开以解决疑难问题，甚至是第三方模块中的错误，这很有用，但大多数情况下这是我们自己的代码。

每个都是单独的git repos。将它们保留在我的文件系统中的单个根文件夹下没有问题（无论如何我还是会的）。但是我需要为每个实例打开一个单独的VS Code实例，来回切换非常麻烦，因为您只能看到文件名，而不能看到应用程序本身的名称。无法轻松找出在哪个窗口中打开了哪个应用程序/模块/项目。在区分多个VS Code实例时，文件名本身提供的有用信息很少。

还有一个未解决的问题，就是有关标题栏信息的可配置性，我也对此进行了评论，但仍未解决。如果可以在标题栏中使根文件夹名称向左冲，那么打开多个项目的问题就不那么重要了，因为在切换任务时，我至少可以看到Windows中哪个打开的实例。这似乎使配置变得非常琐碎，并且至少减轻了在解决这一问题时无法在单个实例中打开多个git repos的痛苦。

jamietre 于 2017-01-09

👍4

@waderyan

我的Web项目由单个父文件夹管理。以此方式进行组织，并为我的存储库文件夹提供快速链接。我也这样做，因为当要重用它们时，我很容易交换到以前的/当前的项目中来提取代码样本。与打开另一个窗口相反，在我的情况下，打开另一个选项卡更容易，而且时间效率更高。
每个Web项目都有自己的git集成，但是对我个人而言，我不需要将.git集成到我的代码编辑器中。对我来说这是一个不错的选择，但不是必需的。由于希望将每个Web项目都保留在我的回购主机中，因此它们具有自己的.git集成。

nickmak 于 2017-01-09

@nickmak @jamietre @pesho感谢您分享您的想法。这是有帮助的，我期待明天与更多人聊天。

@alefragnani我专注于最终用户方案。由于对扩展的影响，我们已谨慎处理此问题。我们将谨慎行事并传达任何api更改。如果您愿意，可以在Twitter上给我

waderyan 于 2017-01-09

👍4

甚至notepad ++也支持多文件夹。这就是不能离开记事本++的原因。
这一天使用javascript需要打开多个项目。

milhcbt 于 2017-01-10

👎2

我从事嵌入式软件工作，通常在整个系统中都需要处理几个文件夹。例如，应用程序代码，供应商库和操作系统代码。

truthmeister6 于 2017-01-12

👍1

我想在这里为同一窗口中的多个文件夹添加用例。

我是一名游戏开发人员，对于我们当前的游戏，我们已经实现了mod支持。我们的游戏有一个客户端，服务器和主服务器项目。编辑mod文件时，通常只能在游戏的mod级别中工作（而不是我们称为实际游戏代码的核心或本机级别），例如，仅在Lua文件中工作，而不是在服务器和服务器上使用C ++和C＃文件。客户）。文件夹通常不能位于公共父文件夹中。

在这种用例中，当仅在mod文件中工作时，过去我们使用Sublime的多文件夹功能来创建仅来自客户端和服务器的顶级mod文件夹的项目视图。这使我们可以避免使用本机文件（C＃和C ++），并在这两个相互之间非常相关的项目中快速编辑Lua文件。

在VSCode中具有多文件夹支持将使我们能够做到这一点，并大大简化了我们对VSCode的采用（我们非常喜欢）。

CWolfs 于 2017-01-12

👍1

上周的通话结果如何？我在Mac上，似乎无法打开VSCode的多个实例，我认为这是一种解决方法。

谢谢！

nowherenearithaca 于 2017-01-15

上周我和韦德打了个电话，很明显，很公平，这不是
优先考虑，他们已经建立了一个非常好的编辑器，现在希望
他们正在扩展它以满足不同开发人员的需求。开发团队是
听着，我很期待看到他们如何去做

2017年1月15日，星期日，21：20 nowherenearithaca， notifications @github.com
写道：

上周的通话结果如何？我在Mac上，似乎无法
打开多个VSCode实例，我认为这是一种解决方法。
谢谢！
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/Microsoft/vscode/issues/396#issuecomment-272724576 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AA16yEIdTFJAnqXHLs_WUvrGBIR9G7f-ks5rSo2DgaJpZM4Gm3nX
。

riotgibbon 于 2017-01-16

👍2

要求很高
标记

jasonshaw 于 2017-01-18

👎4

@nowherenearithaca我与许多用户打了

waderyan 于 2017-01-18

👍15 🎉3

@waderyan ，很抱歉

您的微服务是否共享一个父文件夹？为什么或者为什么不？

是的，为方便起见。当相关服务位于同一目录下时，可以更轻松地找到它们。

每个微服务都被划分到其自己的git存储库中吗？为什么或者为什么不？

是。它们不仅具有不同的存储库，而且还具有不同的加载和调试配置。另外，使用Cmd + P在项目之间切换文件非常有用。全局搜索相关项目，...

期待看到这个动作！

saada 于 2017-01-19

一种解决方案是创建指向您要访问的文件所在文件夹的链接。
这不是理想的方法，但可以提供帮助。

_例：_

/home/myprojet
/home/mylibs
cd /home/myproject
ln -s /home/mylibs
code /home/myprojet

sxslex 于 2017-01-25

👍2

我有3个监视器，我想在所有三个监视器中使用VSCode。如果我无法打开多个实例，则至少支持取消固定选项卡并将其拖到其他窗口中（类似于Visual Studio 2015）。

calloncampbell 于 2017-01-25

👍3

同意。

所有其他文本编辑器都可以执行此操作。微软为什么不考虑这么简单和必要的事情？

iFredus 于 2017-01-30

@calloncampbell该功能在此问题中： https :

rsyring 于 2017-01-31

@calloncampbell @rsyring我不知道我在做什么错，但是通过使用code -n我可以打开任意数量的编辑器实例。

eryshev 于 2017-02-02

如果我理解正确，那么它将在二月份的迭代计划中作为“对实现“多根工作区”，“多文件夹”工作区的初步调查”进行调查：）

ronjouch 于 2017-02-08

👍8

+1 ...
旧版本的VSCode不可能做到这一点，还是我只是在使用Sublime？忘记...
但非常方便。
现在我的Mac到处都是6个窗户，到处都是垃圾...

而且不，我不会打开我打开的所有六个文件夹的根文件夹，因为资源管理器是垂直滚动，需要我永远浏览文件...

edmundtfy 于 2017-02-09

👍2

@edmundtfy有可能升华。 Visual Studio Code从不支持此功能。

ravtakhar 于 2017-02-13

@ min20解决方案非常完美！多文件夹项目，它将改为通过按钮管理多个窗口

g13013 于 2017-02-14

@DeeJaVu考虑到... VSCode具有这些mouseover-tooltip和Ctrl +单击以转到定义。我下载了Sublime的一些扩展名，但将鼠标悬停和Control +单击的内容也无法正常使用。.有什么建议吗？

edmundtfy 于 2017-02-16

在使用Sublime多年之后，我真的很想念这一点。现在，我正在与Intershop（作为前端）合作，每个Cardridge有数十万个文件。如果我必须加载一个完整的网上商店，当您要打开CTRL + P来快速切换到文件或需要搜索时，它的速度确实很慢。

另外，我只是不想在编辑器中使用项目的每个文件夹。作为前端开发人员，我不需要一切。仅需要的文件夹就足够了。

另一个示例：同时创建一个Wordpress网站和插件。为什么我需要包括完整的Wordpress网站？这只会降低您的效率。

我们还有另一个问题：我们的前端框架分为不同的git repos'。打开4个以上的窗口确实是一个痛苦。然后SCSS intellisense无法正常工作（IE。来自core> package的变量）

TLDR； VScode无法用于大型/大型项目

dariusrosendahl 于 2017-02-16

👍4

+1，让我们想象您使用多个自定义模块开发了一个wordpress或drupal。

您的项目根目录是网站的根目录，但是您不希望整个网站成为仓库，您只希望将几个模块或主题分别作为独立的仓库。

即使是最小/最轻的IDE，也应涵盖Web开发中非常常见的用例。

Zmove 于 2017-02-17

👍4

+1

sjova 于 2017-02-22

👎17 👍2

+1，使我能够编辑项目并无缝处理其子模块

ViRPo 于 2017-02-23

👎12 👍1

+1

mackintux 于 2017-02-23

👎15 👍1

这是阻止我们将整个32人开发团队迁移到VS的唯一问题。

微服务开发只是不可行，令人痛苦。

andrewmclagan 于 2017-02-24

👍12 👎2

+1

jflepp 于 2017-02-24

👎15 👍1

+1，绝对有用，我决定从sublime转到vscode，但是由于缺少此功能，我想我会一直使用sublime直到一天。

lushibi 于 2017-02-25

👎4 👍2

它是一个非常必要和基本的功能。我不敢相信这位出色编辑的开发者为什么会忽略它。没有此功能将毫无用处。这使我无法从Atom切换到VSCode。

usmanahmed 于 2017-02-25

👎14 👍1

请添加此功能。在使用Sublime和Atom之后，这对我来说是编辑器的必要功能。当然，由于git集成，这并不容易，但这是我最喜欢的编辑器中需要的。

DFelten 于 2017-02-27

👍3

+1

loustefanski 于 2017-02-27

👎18

+1紧急需求

gsmental 于 2017-02-28

👎21 👍1

+1如前所述，要从Atom迁移到VSCode，我们确实需要此功能。

nogdacosta 于 2017-02-28

👎19

评论前注意
*请!!!! 用“ +1”停止评论

您的每条无用评论仅以该主题即可分散一百多个人的注意力！
如果您想支持此功能-它会在第一条消息中引起您的注意！
如果您要订阅更新-这是主题右侧的“订阅”按钮
尊重其他成员，他们被迫阅读您的“ +1”，“非常需要”等

buzzzzer 于 2017-02-28

👍41 🎉8 ❤7 😄2

作为参考，Sublime Text（例如）安排项目的方式是通过“包括”文件夹树，并且项目中每个“文件夹”都具有唯一选项。

为了实现这一目标，Sublime Text项目文件的JSON如下所示：

{
    "folders":
    [
        {
            "name": "Front-End (web-forms)",
            "path": "source/www/forms",
            "file_exclude_patterns":
            [
                "*.sublime-*",
                ".gitignore"
            ],
            "folder_exclude_patterns":
            [
                "node_modules",
                ".idea",
                "bin",
                "fonts"
            ]
        },
        {
            "name": "CORE C# Server Components",
            "path": "Source/Server",
            "file_exclude_patterns":
            [
                ".gitignore",
                "*.resx",
                "*.designer.cs",
                "*.StyleCop",
                "*.testsettings",
                "*.cache",
                "*.user",
                "*.vsmdi"
            ],
            "folder_exclude_patterns":
            [
                "bin",
                "obj",
                "TestResults",
                "Service References"
            ]
        },
        {
            "name": "DB schemas & utility scripts",
            "path": "Source/Database"
        },
        {
            "name": "Grunt Build source",
            "path": "Build",
            "folder_exclude_patterns":
            [
                "dist",
                "node_modules",
                "TestResults"
            ]
        }
    ],
}

如您所见，每个包含的文件夹都是相对于项目路径的（在Sublime Text中，它是*.sublime-project文件的路径）。此外，每个文件夹都有一个部分，用于排除带有通配符的文件和文件夹模式。非常适合忽略（如上所示）测试结果，不应编辑的库，插图和其他内容。

这是我不进行切换的最后一个原因。

doublehelix 于 2017-03-02

👍13

这非常有用！

zhaopengme 于 2017-03-08

👎7 😕1 👍1

+1
示例：需要检查该应用程序引用的其他模块中是否尚未实现某些功能，以免重复功能

显然，模块存储在文件路径中的其他位置，而不是应用程序本身中，并且当您只想快速访问文件并阅读代码时，仅使用一个屏幕就很难使用多个窗口。
我说的是AngularJS应用，它们不需要部署或其他任何东西，只需要一个运行中的服务器即可。
当我可以直接从Tomcat直接打开App文件夹并使我的更改实时生效时，为什么还要烦恼其他文件结构的开发。

不会，没有父文件夹，除非您建议将Tomcat服务器文件夹作为一个项目打开（这就像建议我将整个HDD作为一个项目打开，因为那样便可以打开所有文件）。

poparazvandragos 于 2017-03-09

😕1 👍1

哇，我卸载了atom来试用VS，并且自2015年以来未添加此功能。

stoffeastrom于2015年11月21日开设此刊物

令人沮丧。：失望：

PS：打开master文件夹并不是完全解决方案，因为它也会打开所有不需要的文件，从而超出了此票证的目的。

nevinm 于 2017-03-10

👍7 😕3

确实令人沮丧。但是，再次令人沮丧的是，人们仍然抱怨一个很棒的，免费的开源编辑器（每个月不断地增加一些新功能）。也不会让每个人都在观看有关此话题的评论的垃圾邮件而感到沮丧。

_{（现在我是垃圾邮件发送者之一，我猜：grin :）}

gkalpak 于 2017-03-10

👍9 😄3 😕1

更新：当前的计划是在3月/ 4月的迭代中对此进行研究。

请参阅https://github.com/Microsoft/vscode/issues/21923了解三月的迭代计划：

调查多根，多文件夹工作区＃396 @bpasero @Tyriar

Tyriar 于 2017-03-10

👍28 ❤8 🎉8

+1

mugi-luffy 于 2017-03-15

👎22 😕1

要共享一个完善功能描述的真实示例：WordPress主题/插件开发示例。

在其他编辑器中，我将几个文件夹设置为“书签”，以使到相当大且复杂的文件树变得更易于管理。一种是webroot，这是我希望从其启动的任何调试和代码完成功能的根（环境）。第二个是实际项目，一个主题文件夹或一个插件文件夹，在我的工作流程中，该文件夹是版本控制的根目录。有时，我会设置其他文件夹作为参考，例如父主题或模板主题，或与之集成的插件，我需要经常参考/阅读。

因此，此处设置的功能是：1.可以将git root和search root设置到不同的位置。 2.纯粹可见的文件夹书签系统，可以整理文件树面板。

对于git根和项目根相同的线程上的某些线程，似乎学习和使用子模块就足够了，然后只需大约2.即可获得嵌套文件夹的简洁明了的视图。

我确定线程上的某些人实际上是在要求字面的多项目支持，但是我认为大多数人只是在寻求更简单的文件夹书签想法。

我还要求一种将一个定义为项目根（搜索/调试），另一个定义为git根的方法。（请随意忽略我对事物的不良命名。）

WraithKenny 于 2017-03-15

👍5 😕1

我的解决方法是简单地创建一个父文件夹，并在其中创建与我想要的所有项目的符号链接。
_例如。_

我有这些项目

1. my-app-api
2. my-app-client

我创建了一个名为_my-app-all_的文件夹（名称与此处无关），并且在其中创建了两个指向my-app-api和my-app-client的符号链接，然后在VSCode中，我只需要打开my-app-所有

脚步

mkdir my-app-all
cd my-app-all
ls -s ../my-app-api
ls -s ../my-app-client

笔记：
git集成无法正常工作

DannyFeliz 于 2017-03-20

👍2

@DannyFeliz，这应该被标记为该问题的答案，并在顶部张贴，以供大家查看...我也在Windows上使用MKLINK命令对此进行了测试。
用法示例：

以管理员权限打开命令提示符
转到您的项目文件夹
3. [可选]创建链接文件夹
使用MKLINK / D“ link_name”“您要引用的文件夹的路径”

当您以VS代码打开项目时，您将看到引用的文件夹及其中的所有文件/文件夹。

编码专家们，大家好！

poparazvandragos 于 2017-03-20

👎5 👍2

这不能使Git集成正常工作。

2017年3月20日星期一，下午2：42，poparazvandragos [email protected]
写道：

@DannyFeliz https://github.com/DannyFeliz这应该标记为
这个问题的答案，并张贴在顶部供所有人查看...我已经测试过
在Windows上也可以使用MKLINK命令。
用法示例：
以管理员权限打开命令提示符
转到您的项目文件夹
3. [可选]创建链接文件夹
使用MKLINK / D“ link_name”“您要引用的文件夹的路径”
当您以VS代码打开项目时，您将看到引用的文件夹
以及其中的所有文件/文件夹。
编码专家们，大家好！
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/Microsoft/vscode/issues/396#issuecomment-287907310 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ABEOBVKz2bqFsRdfvyOpcFW2e_26HV5bks5rnvLWgaJpZM4Gm3nX
。

ehartford 于 2017-03-20

👍7

@ehartford我说的是答案，而不是答案，因为我们大多数人都在寻找这个确切的东西，在同一个VSCode窗口中显示多个目录，它们位于不同的位置。
符号链接只是这样做，但是在Windows上工作时，这并不是我想到的解决方案。
它必须经过2年的时间，Linux / OSX开发人员才能向我们展示最简单的解决方法。
我很高兴最终决定对这个问题发表评论，因为我已经找到了所需的解决方法
仅仅12天之后，当我最需要它时。

不应放弃该问题，因为如果开发人员选择介入此问题，则可以做更多的事情。
但是对于我们大多数人来说，这是令人满意的。我只是建议以某种方式将其放在首位，这样人们就不会浪费时间阅读所有其他评论，直到他们发表此评论。由于线程的大小，有些人可能只是忽略了它。

当我看到人们已经跃跃欲试时，我将对其进行编辑，因为我找到了实现自己想要的方法的方法，并试图使其他人更容易找到替代方案，即使不是很完美。顺便说一句：您始终可以使用VSCode中集成的命令提示符来拉/提交/推入单个链接文件夹中的文件，但是为什么要解决此问题。

poparazvandragos 于 2017-03-21

👎3 😕2

如果没有Git集成，那将是一个完全的初学者。无论如何，我都不认为这是可以接受的解决方案。期待实际的解决方案。最好的祝福。

EricForgy 于 2017-03-21

👍2 👎1

如果有帮助-谷歌appengine nodejs客户端的结构如下：

https://github.com/GoogleCloudPlatform/google-cloud-node

我很希望能够在这样的解决方案中打开/调试/工作（即使一次只包装一个）。我很希望能够以这种风格编写基于Typescript的项目/库。

感谢您所做的所有出色工作！

chadbr 于 2017-03-21

喜欢VSCode，但是在处理多个项目时比较废话。但是我能理解为什么推迟了该功能，因为由于嵌套等原因，它使诸如源代码控制之类的多种事情变得更加复杂。

我很想使用“项目快速切换”功能或在一个窗口中“制表”多个vscode实例的功能。

replete 于 2017-03-22

👍7

完全同意，请支持同一个窗口中打开多个项目文件夹。这功能很重要。

ghost 于 2017-03-23

👎12 👍3 ❤2 🎉1 😄1

@replete这不是您问题的完美解决方案。但是，请尝试项目经理，这对我现在有所帮助。

dariusrosendahl 于 2017-03-23

@dariusrosendahl是的，今天早上很有趣地发现了它！现在做这项工作。

侧边栏只有5个图标，添加“项目”侧边栏不会花费太多。但是，vscode产品所有者似乎对它的最小化非常挑剔。 IMO太少了，因为它正成为IDE。

replete 于 2017-03-23

@replete很高兴知道它会有所帮助😄

实际上，在_experimental API_中用于创建所谓的_Tree Explorer Contribution_（就像“符号”面板-https://github.com/Microsoft/vscode/issues/15485）。这样，扩展程序可以在活动栏中添加一个图标。

我会在您的扩展名中加上您的建议，谢谢👍

alefragnani 于 2017-03-23

+1

DilwoarH 于 2017-03-27

👎21

@dmccaffery

我个人并不关心此功能是否会出现在产品中-我理解为什么有些人想要它，但是我要指出的是，它确实使所有内容变得更加复杂。

然后，也许不要以对该功能的负面评论以及有关VSC如何不是IDE的话题来主导对话。我认为，如果需要进一步澄清一个立场，那么一个回应/否定投票就足够了，或者至少是两个。

此外，“不是IDE”的论点没有意义。其他非IDE也允许这样做。

例如：使用正则表达式进行搜索时-我要搜索哪个工作区？一？所有？

没什么大问题。搜索全部，或使用选择器将搜索范围限定在一个打开的工作区中。同样，其他“非IDE”（以及IDE）已经可以处理这种情况。

bugpowder 于 2017-03-31

👍9

我通过为每个“工作区”创建一个目录并符号链接到要在该工作区中看到的项目来解决此问题。

glesperance 于 2017-03-31

😕4

我看到了

对多根，多文件夹工作区的初步调查＃396 @bpasero @Tyriar

根据https://github.com/Microsoft/vscode/issues/21923完成此操作吗？ :)

dariusrosendahl 于 2017-04-03

👍2

我们（团队的子集）对所涉及的工作量以及所遇到的挑战进行了初步调查，下一步是与团队讨论结果并制定计划。我们将在本周进行4月发布的计划，因此由于这项工作很快就会出现，因此我希望有更多细粒度的计划项目。

bpasero 于 2017-04-03

👍47 🎉11 ❤5 😄2

screen shot 2017-04-06 at 12 09 26

如果我参加聚会还不算太晚，那么这是一种不错的方法。
当您转到“资源管理器”时，我们已经有两个部分。一个用于打开的文件，另一个用于当前打开的文件夹的资源管理器树。

理想情况下，我们可以在同一窗口中打开更多文件夹，并将它们添加到此处的自己的部分中，可以对其进行扩展以查看资源管理器树。

可以对“源代码控制”部分执行相同的操作。在“资源管理器”中打开的每个文件夹的一个小节。所以是一对一的关系。

这样，也许我们可以使每个人都开心。如果需要，我们支持在同一窗口中打开多个文件夹，并且GIT集成仍然有效，并且能够分别处理每个“项目根”。

danechitoaie 于 2017-04-06

👍25

在同一窗口中打开多个项目对我来说也是一个重要功能。通常，我也会打开项目来复制一些基本应用程序。我只是安装Visual Studio Code，因此我将返回Atom

pedrolucasoliva 于 2017-04-07

👎12 👍6 😕1

+1我想向其他开发人员展示VSCode的价值，但无法在同一窗口中打开两个文件夹是一个大问题。我希望这能得到更高的优先级。

jtstroup 于 2017-04-14

👍7 👎4

只是我的两分钱：

到目前为止，“ monorepo”一词并未显示在该线程中

我的monorepo将配置根源集中在多个根中，其中每个根都由包含根的文件夹中的“ .root”文件标记。

并非每个根都是外部git存储库，但是它们允许部分覆盖全局配置。

我的主要痛点是，搜索文件和/或符号不会优先考虑我的根目录内容

fgarcia 于 2017-04-15

👍2

我认为需求可以分为约4个单独的需求，这些需求可能彼此直接相关（也可能不直接相关）：

支持资源管理器中的多个文件夹
支持搜索中的多个文件夹
在源代码管理中支持多个文件夹
在调试中支持多个文件夹

从我在该线程中看到的内容来看，将它们分开可以支持更多场景。当然，应该仍然有一些“主”文件夹，这会影响已配置/选定文件夹的保存方式。

kalinkrustev 于 2017-04-15

我不明白为什么大多数评论都谈论多根或多文件夹资源管理器解决方案。实际上，我认为尝试以IDE方式实现它真的很糟糕。它增加了复杂性，并且肯定会影响性能（加载时间，git刷新……）。

我认为该功能非常重要，基本上需要对所有相关项目有一个直观的了解，并在项目窗口之间快速切换！

我们有两个选择：

在一个窗口中实施：就我而言，它引入了许多其他问题，git的多个项目根目录，search ...这对于UX来说非常糟糕，并且可能会给编辑器带来bug和复杂性。
实现可视化的切换机制，并在每个项目中保留一个窗口：这是最安全，更方便的选择，而成本却非常低！ @ min20发布了有关组之间松弛的切换按钮的视觉效果，我觉得很合适！

spack

我希望此功能能够实现，但不能作为多根解决方案！小型编辑器的主要优点之一是操作简便，快捷， muti-root != simplicity & speed

g13013 于 2017-04-15

👎6 👍2

我必须完全不同意@ g13013您看到Sublime的实现了吗？它非常简单，而且比Visual Studio Code快很多。即使启用了所有GIT插件。

我们不是在谈论在1个编辑器中使用多个项目。我们在谈论的只是使用所需项目的文件夹。

例如，我在Intershop商店工作。我不需要很多东西，只有我需要编辑的墨盒。 80％的文件夹和文件对我来说是无用的，只会使编辑器更重（请相信我，它会使速度大大降低）。

如果存在大量重复文件，则在Visual Studio中使用“快速打开”也是不可用的。您通常不确定是否会一次又一次地打开正确的文件，它会因大量文件而减慢速度。

dariusrosendahl 于 2017-04-15

👍7

我了解，但是，在过去使用sublime和atom时，我最终得出的结论是，除了具有探索项目文件的能力之外，没有“ muti-root”功能的项目都可以解决任何其他问题。大型项目，甚至在发现冻结时，sublime都没有开箱即用的“ git”和“ debug”功能集成....引入muti-root将引入很多与git集成相关的问题，对搜索没有影响性能...甚至UX也受到影响，例如在大型项目中探索srcoll问题。

g13013 于 2017-04-15

👎3

很奇怪，对我来说恰恰相反。

也许是因为99％的时间我只将我需要的内容包含在Sublime或Atom :)中，而这正是我们想要的。

也许这只是您使用编辑器的方式。我习惯于使用CMD / CTR + P并键入我想要的确切文件。如果您必须在项目的根目录中包含大量重复文件，那么这是不可能的。（将小盒/文件留在此处以比较原始内容：））或类似wordpress的文件，其中有很多同名文件。

dariusrosendahl 于 2017-04-15

😄1 👍1

你好，
是的，多文件夹的想法很好，而且不会破坏很多东西。每个其他文件夹可以是一个带有前缀的新子节，以指示它对主文件夹是陌生的。 Primary用于调试和Git。用户可以右键单击任何外部文件夹并将其设置为主文件夹。您获得的收益：
1）能够查看所有文件夹和文件并根据需要打开它们。
2）重新进行主要工作。

现在，如果有人想一次打开多个项目，那么他们应该打开一个新的发行请求。这增加了许多人概述的显着复杂性。插件不等同于内置插件。如果有一个具有匹配的内置功能的编辑器，则应指出该名称，以便其他开发人员可以检查其工作流程如何适合这种功能。谢谢。美好的一天。

pr-yemibedu 于 2017-04-17

👍1

将我添加到认为这是唯一阻止我转移到VSC的交易破坏者的用户列表。我发现项目的Sublime实施已成为现实。例如，如果需要在“志愿者时间”应用程序上工作，则打开用不同的文件夹（主项目文件夹以及另一个包含图像的文件夹）填充的项目。那是我为那个项目准备的工作。如果需要切换到“ Exchange Calculator”应用程序，则可以将整个工作集交换到该项目，或打开一个包含该项目的新窗口。
另一个用例是使用CMS时。如果我正在为CMS开发插件，那么我可以为该插件创建一个项目，该项目是Git存储库，而对于整个CMS，则可以有另一个项目（未进行Git化）。我可以根据需要在两者之间切换，并使我的Git关注点分开。
在我看来，VSC看起来像是未来，但并非不能保留单独的工作文件夹集。

mduey 于 2017-04-18

👍8

你好，
我只看到Sublime Text支持带有项目文件的项目经理的事情。

老实说，我也使用Atom，并且使用了多文件夹功能（内置），该功能使我可以同时打开文档文件夹和当前项目文件夹。启用初级和二级辅助器似乎确实有些悬而未决。可能是一个简单的箭头或开始表示主要。谢谢。美好的一天。

pr-yemibedu 于 2017-04-18

对于它的价值，这是我的用例。我开发的游戏分为三个存储库；一个用于引擎的Git存储库，一个用于游戏代码+内容的hg存储库，以及一个用于许多项目中通用的游戏代码的hg存储库。该公司的Sublime Text插件还有一个汞仓库。通用存储库是游戏存储库的子存储库。

我希望在下一个工作场所再次使用许多存储库。

将所有这些都放在同一编辑器实例中非常方便，我认为所有这些都可以在VS Code中获得适当的SCM是有意义的。

我希望搜索默认情况下会搜索所有映射的文件夹。一个不错的好处是能够临时打开/关闭要搜索的文件夹。（例如，当我只想在游戏引擎中查找事物时）

很多人说VS Code不应该对此提供支持，因为A）他们不需要它，并且B） VS Code是一个简单的文本编辑器。第一个原因是不好的-每个人使用的功能很少。第二个原因... VS Code不仅仅是一个简单的文本编辑器，它还具有调试，SCM，插件的功能。其他“简单文本编辑器”（例如Sublime）具有多个文件夹支持。作为对性能保持坚定态度的人，我看不到添加此功能将如何以任何有意义的方式影响性能，特别是对于始终只使用一个文件夹的人。我们可以请关注我们如何想的功能，这方面的讨论，而不是为什么我们不希望它。

Srekel 于 2017-04-19

👍10

@Srekel您可以在当前的编辑器中包含如何工作的屏幕截图吗？听起来像是使用内置和插件的文件夹和项目的混合。希望人们在一个营地将很难变动公告将这一类型的功能。对于B营的人来说，他们是对的。如果您无需陷入困境，则可以使用开箱即用的应用程序快速完成操作。保持接近该值可能有助于实现如此快速的更新周期和整洁的界面元素。

有关如何完成此操作的一些事项包括：

了解范围，上下文，会话，视图和当前关系。
上限（超过256个文件夹吗？）
主要影响区域（编辑器标签，设置，scm，git，扩展名）。
工作区设置覆盖或冲突。

关于VSCode在这些需要补偿的领域中理所当然的事情，到这里来再好不过了。谢谢。美好的一天。

pr-yemibedu 于 2017-04-19

+1

hyperjelly 于 2017-04-25

👎23

+1。我有30多个模块，每个模块都有一个自己的git存储库，我希望可以在一个环境中访问和使用它们。我认为这就是大多数js / node开发人员所做的。有了VSCode，这是不可能的，遗憾的是，这对我来说是一个大难题。

mhzed 于 2017-04-27

👍11

+1

它自2015年以来一直开放，但尚未修复。它是所有编辑器中最想要的功能，但是遗憾的是vscode没有它。

Jeyanthinath 于 2017-04-28

👎9 👍1

+1

在使用Tab键进行切换时，我经常将一个VS Code窗口与另一个窗口混淆。

我认识的所有其他编辑器都具有此功能（Atom，Sublime，Brackets ...）

将符号链接添加到我的项目是一个hack，需要我更新.gitignore。打开父目录很烦人，因为然后我的文件窗格中充满了其他我不在乎的项目。

kdumovic 于 2017-04-28

👎5 👍2

四月迭代计划显示完成的任务“调查到多根，多文件夹工作区”。调查的结果是什么？
@bpasero @tyriar

gulshan 于 2017-05-02

👍29 🎉1

+1

vulkanosaure 于 2017-05-02

👎15 👍1

对不起，如果我太渴望了。你们正在忙着发布代码。

gulshan 于 2017-05-02

👎6

你好，
“打开文件夹”对话框应被视为“打开文件夹”。因此，如果我在特定的父文件夹下，则可以在对话框中突出显示要同时打开的两个或多个子文件夹。通过合并此功能，这将是一个受欢迎的补充。谢谢。美好的一天。

pr-yemibedu 于 2017-05-03

+另外一个

oooeeee 于 2017-05-05

👎12

以前从未在GitHub线程中见过这么多省力的注释，尤其是后表情符号。天啊。

我真的很喜欢这个功能。就像其他人已经说过的那样，许多现代项目都是模块化的，例如在一个仓库/项目中是前端，而在另一个仓库/项目中是后端/ api。您通常会希望将它们作为一个整体一起工作。

samhh 于 2017-05-05

👎9 👍4

这是我没有放弃Atom的唯一原因。

intijk 于 2017-05-09

👍7 👎5

微服务和无服务器平台与长期存在的“便宜的回购协议”相结合，是为什么必须这样做。可以打开约30个[小型]存储库并同时处理多个项目中的文件，这并不罕见。期望人们在那么多窗口之间切换，或者将文件视图排列卸载到桌面环境窗口管理器将无法正常工作。

martinjco 于 2017-05-10

👍6

你好，
您如何现在管理@martellaj的30个
您是否由于环境中的其他限制而这样做？也许编程语言没有智能感知？可以读取API以提供功能签名的扩展会有所帮助吗？
像F＃这样的语言具有一个称为类型提供程序的功能，其中之一可以做到这一点并使网络编程更加容易。这并不是要减少对多个文件夹的需求，而对于如此大的活动工作空间，您可能至少还会遇到其他一些问题。谢谢。美好的一天。

pr-yemibedu 于 2017-05-10

@ pr-yemibedu，我认为@martinjco的意思是他没有打开文件，但如果我们有一个多根结构，他将可以快速访问该存储库。想象一下，只需将CMD + P压缩到您需要的任何文件即可；

当前问题是我们必须打开文件或至少在30个不同的窗口之间切换，因为VScode不支持它。

实际上，由于缺少功能，我最近切换回了Atom。我目前正在开发一个有9个回购协议的项目。我不希望同时打开9个VScode寡妇，但是我只想使用快捷方式转到所需的文件。

dariusrosendahl 于 2017-05-10

👍2

同意@dariusrosendahl的评论。我是一个新手编码员，必须参考旧项目才能编写新项目。希望这会很快改变，但是在崇高的氛围中，我可以轻松地拥有三到四个项目文件夹，并比较它们是否在同一会话中打开
screen shot 2017-05-11 at 12 48 57 pm

如果我们能在Visual Studio中得到它，那就太好了

nuno1895 于 2017-05-11

👍9

你好，
我同意上述观点，因为您可以看到我以前的帖子都赞成此功能。 martinjco发表了一个确切的评论：

可以打开约30个[小型]存储库并同时处理多个项目中的文件，这并不罕见。

nuno1895显示的是我今天需要使用多个文件夹但一个简单的主要焦点项目时如何使用Atom。实际上，我同时使用VS2015，gedit，vim，notepad和notepad ++进行主动开发。每种技术都有各自的优势，而其他优势却无与伦比。

我只是想了解是否有一个核心点可以弄清楚。我们所有人都希望将其付诸实践，并得到愿意花时间在上面的开发人员的青睐。这就是为什么我问今天如何处理。 9 vs 30可能不会引起我那么大的兴趣来回应，但是我想知道人们将vscode与什么进行了比较，即使我看另一种工具是否值得。

我只看到Atom和SublimeText被用作比较的基础并提供了有用的屏幕截图。欢迎更多的讨论，经验和反馈，以使该方法得到接受和实施。谢谢。美好的一天。

pr-yemibedu 于 2017-05-11

👍1

可能没有足够强调的一点是能够在文件夹集（项目）之间快速“翻转”的能力。在Sublime中称为“快速切换项目”。当您单击该菜单项时，会弹出一个包含所有项目列表的弹出窗口，当您选择一个项目时，编辑器会显示该文件夹以及所有上次打开的文件。
例如，如果我在Project A中工作，并且打开了app.js和index.html文件，然后切换到Project B，它将关闭Project A并显示ProjectB。如果我然后再切换回Project A，它将向我显示该文件夹以及我离开时的app.js和index.html（即使还有未保存的编辑内容）。
如果需要同时打开两个项目，则可以只打开编辑器的两个实例。
关键是我能够将所有东西都放在单独的存储桶中，并且可以在它们之间快速切换。

mduey 于 2017-05-11

👍1

+1

ventusjk 于 2017-05-12

👎16

你好，
我了解了该功能。在不浏览Sublime Text的情况下切换项目会指出一些好处和坏处。最好对在工作区设置文件中打开的多个文件夹进行编码。如果该文件放置在错误的位置，则可以创建诸如folders.json之类的文件，以保留可用文件夹和文件的当前状态，并为当前工作集打开该文件夹和文件。谢谢。美好的一天。

pr-yemibedu 于 2017-05-12

👎3

几个月前，我开始使用VSCode，总的来说，我感到非常满意。我会在合唱团中加点声音，说这个缺失的功能对我来说是个大难题。是否还有其他任何有体面的编辑器都具有此限制？无论如何，它应该是固定的。 :)

logidelic 于 2017-05-15

👍4

这是我新工作的设置：
核心技术的一个仓库。假设路径为C：/ mygamengine /
游戏代码的一个回购。已同步到C：/ mygamengine / mygame
游戏内容（纹理等）的一个回购：C：/ mygamengine / mygame_data

这三个都是git。它们没有设置为子存储库，它们只是同步到这些文件夹。

最好我只想在VS Code中打开根文件夹，并让它自动找出本质上是三个不同的项目，并且mygame下的文件属于该git存储库，而不是mygameengine中的那个。

我希望能够为此工作区设置每个存储库都不同的设置（例如，我可能想在引擎项目上运行lint，而不在游戏代码上运行lint）。如果默认情况下在所有三个项目上都设置了工作空间设置，那也很好。

Srekel 于 2017-05-15

👍3

哇，这还没有解决？我希望用VS Code替换Atom，因为据评论，它更快并且不会落后于Atom。
我的主要项目是两个Git存储库，一个后端，另一个前端。本地都在同一个文件夹中，但是如果Atom或VS代码打开该父文件夹，则不会识别到Git状态。
在Atom中，我只将两个文件夹都添加到我的工作区中就可以了。

edwinramirez 于 2017-05-15

：sparkles：更新：sparkles：

自上次更新以来已经有一段时间了，所以我想我会带给大家最新的信息。我自己， @ bpasero和团队中的其他成员已经确定了实现多root用户的大多数问题，并且目前正在进行一些模拟，并找出UX的更多细节。

为什么要花这么长时间？

花费了很长时间，因为此功能不是我们唯一的责任，而实现多树根的工作非常艰巨。对于初学者，VS Code中的所有组件都是在假定在任何给定时间仅打开一个文件夹或没有打开文件夹的前提下设计的。当您拥有像我们这样大的代码库时，就需要进行大量工作才能使其更加灵活。

举一些例子，这是到目前为止我们已经确定的一些更大的痛点：

扩展API公开了一个workspace.rootPath ，当我们添加对多根文件夹的支持时，这是不够的。我们希望避免破坏这些扩展，并在必要时提供迁移路径。
工作空间设置在多根世界中交互的方式略有不同。以workbench.statusBar.visible为例，这在工作空间设置中当前是允许的。我们将不再能够支持此操作，因为如果在2个文件夹中进行定义，它将导致奇怪/无聊的行为。我们正在寻找如何处理这类案件的过程。
为了支持多个文件夹，SCM提供程序（git）可能需要大量的UX工作：是否需要引入“活动项目”的概念？应该明确设置（右键单击文件夹并进行设置）还是隐式设置（查看活动文件的文件夹）？它应该是全球概念还是仅限于该特定功能？等等

我们不想急于提出一个经过深思熟虑的解决方案，因此我们要花时间，并认真考虑可能存在的问题及其对每个组件的影响。准备好了就会来。

迄今为止的评论摘要

我只是花了几个小时来研究巨大的线索，以整理到目前为止的反馈。对其中的一些东西进行分类有点困难，但这就是人们通常所追求的（我在解释）。

我想跨多个文件夹进行git集成
当前的文件夹切换和/或OS窗口管理UX很麻烦
我想在多个文件夹中搜索
我想跨多个文件夹进行调试

顾虑

重构在整个项目中还是在单个项目中起作用？
我要在Git上从事哪个项目？
我的搜索将在哪个文件夹中运行？
不要破坏工作区设置
不要破坏扩展程序-向扩展程序开发人员警告有关新API的信息
一个Slack样式的选项卡式UX对我来说还不够，实际上只是将窗口管理从OS转移到VS Code-我希望能够从单个Window（即一组编辑器组）中访问项目中的所有文件。
“就我而言，它引入了许多其他问题，多个项目都出现在git的根目录下，搜索.....对于UX来说这非常糟糕，并且可能会给编辑器带来错误和复杂性。”

其他的建议

我只想在“ git文件夹”中打开存储库的子集
我想要一种在单个文件夹中搜索或按项目组织搜索结果的好方法
我希望能够导航到相关代码以快速阅读
我想为不同的文件夹运行不同版本的TypeScript
VS Code太慢了
我想让一些项目始终开放供参考（例如主题/模板）
我想让VS Code识别任何目录中的.vscode / settings.json文件（这将有助于解决问题）
让我定义一个项目根目录（搜索/调试）和一个git根目录
Sublime优雅地处理多文件夹git集成
与Slack的UI相似的选项卡式文件夹（即，一些活动项目范例）
资源管理器中每个文件夹的单独部分
将文件夹用作主要文件夹，将其余文件夹用作链接/子文件夹
我想要像升华一样的快速切换项目（快速切换+保留工作区布局）
这种工作空间管理风格对以下各项特别有用：npm模块，julia，heroku PaaS，wordpress，drupal

当前解决方法

以下是当前的主要解决方法：

开放共同的父母
Git项目经理
专案经理
将文件夹符号链接为“主文件夹”的子目录

什么时候发表评论？

请避免：+1：或“我想要这个”注释。当对此问题发表评论时，除了还有更多人点击了“订阅”按钮之外，还会收到153位对此发表评论的人。 评论也会掩盖团队更新，因此请注意这一点。一定要评论一下，如果它增加了对话的话。

Tyriar 于 2017-05-16

👍155 ❤45 🎉28

可以说，比起具有多个根而具有更多用途的功能是添加具有可配置工作集的功能。这将使您能够打开一个共同的父母，但是在该项目中有许多文件夹组合。

通常，这对于任何项目都非常有用，因为它能够一次在较大的代码库中“专注于”某些文件/文件夹，而不必每次都更改整个根目录的配置。

tal 于 2017-05-18

👍4

没有关于此功能的计划？

jackie-qiu 于 2017-05-18

👎68 👍1

您可以在@Tyriar的评论以及相关链接中查看此功能的计划：
https://github.com/alefragnani/vscode-project-manager/issues/46
https://github.com/Microsoft/vscode/issues/26068

andressltz 于 2017-05-18

👍1

我们希望为此分享我们的设计并获取您的反馈。为此，我们将召开许多电话会议，我们将逐步介绍我们的设计并讨论您对设计的反应。

如果您想参加这些讨论并帮助我们正确设计，请与我联系（向我发送电子邮件-microsoft dot com上的stevencl），我将进行设置。

我们希望将这些讨论安排在6月1日（星期四）和6月2日（星期五）进行。

stevencl 于 2017-05-30

👍35 ❤10 🎉6

@Tyriar @stevencl谢谢大家！：拍：

svipas 于 2017-06-01

感谢大家参加今天的会议。会议录音已发布在这里

第1组-https: //youtu.be/48Y6tB3DN1g
第2组-https: //youtu.be/kHL6Rt-dLm0

请观看视频，并分享您对设计的任何其他评论。

stevencl 于 2017-06-01

👍25 ❤5

@stevencl感谢您运行研究并使之可用！

bpasero 于 2017-06-01

👍1

很棒的视频，谢谢！一些反馈：

👍👍👍了解VSCode今天的工作原理的整体简单设计和自然扩展。你们以简单，优雅的方式处理了许多复杂的情况。为此表示敬意！
我喜欢聚合的SCM通知在左下角，从我的观点来看，不需要做任何更改，但有一个例外：单击SCM通知后，我将跳过弹出窗口，直接进入SCM面板。点击次数减少=对我而言总是更好。
像阿列克谢（Alexey）所建议的颜色编码词根是一个有趣的想法，可能会有所帮助。
搜索：对文件夹进行作用域范围对我来说很重要，我想当前的“要包含的文件”字段可以用于此目的，只是想确保即可。
我唯一不确定的是持久性并在打开path时打开所有additionalFolders path 。在上一个示例中， express-project显然是“主项目”，这有点说得通，但我不确定上一个示例： express和express-plugin感到相等，就像真正的兄弟姐妹一样，我不确定我希望打开express也会打开express-plugin 。
- 从某种意义上说，它背后的数据结构应该只是路径的平坦列表，而不是“ path”然后是“ additionalFolders”。
- 我不确定一个主路径的概念是否有用。在我的项目中，可能不是。
- 要打开多根工作区，除了当前的_File> Open folder_之外，我还希望有一个顶级命令，例如_File> Openworkspace_。
- 总的来说，我对此不太确定。抱歉，我没有更具体的建议。

再次感谢，VSCode将获得新的超能力。

borekb 于 2017-06-04

👍6

感谢您分享视频。我想支持“每个根文件夹一个部分”的设计：

one-section-per-root-folder

最初，我期待其他（类似Sublime-Text）的设计，但是在看到“每个根文件夹一个部分”的选择之后，对我来说很明显，这种方法具有以下优点：

文件夹之间明确，明确的区分和分隔（特别是如果我拥有两个或三个以上的文件夹，当我使用其他编辑器和IDE时通常会出现这种情况）
加强了根文件夹是一个单独的（子）项目的概念
快速访问子项目命令（例如“新文件”，“刷新” ...，以及将来可能右键单击以在该特定子项目上启动任务（例如“重建”）;））
正如第二组所提到的，使用这种设计，不太可能出现文件夹名称截断问题

maddouri 于 2017-06-04

👍30 🎉1

关于“每个根文件夹一个分区”的概念……我真的不确定这对我和大多数用例是否都适用。每当我遇到多方面的情况时，我通常都会遇到很多情况。不只是2或3。
我不确定这种方法将如何扩展？

TurkeyMan 于 2017-06-04

👍3

对于当前的类似文件夹的布局，还有一个论点是它与monorepo的显示方式一致。例如，比较：

monorepo/      <- contains .git
  project1
  project2

与

microservices/
  project1      <- contains .git
  project2      <- contains .git

VSCode应该确实非常相似地对待这两个：monorepo已经存在（提交：自然，搜索：“要包含的文件”，多个自述文件：它们的文件夹显示在编辑器选项卡中；等等）。 IMO应该尽可能多地遵循此原则，当前的设计效果很好。

borekb 于 2017-06-04

@stevencl我还不完全了解的一件事：该解决方案会带来.vscode设置的作用域（甚至是层次结构）处理吗？就像，如果我每个顶级文件夹有.vscode美元，这些设置将单独应用吗？它们会以某种方式汇总到项目根吗？还是只计算“主要” .vscode ？

borekb 于 2017-06-04

由于@maddouri列出的相同原因，我更喜欢“每个根文件夹一个分区”的设计。此外，使用了另一种方法（在Atom中）后，从视觉上看，当多个高度分层的文件夹打开并展开时，很难找到新的根文件夹在哪里开始。

pesho 于 2017-06-04

👍5

感谢您的设计更新，看起来真的很棒！

UI中是否可以同时使用多个工作区？这样您就可以轻松地在它们之间切换。例如，您有以下内容：

EXPRESS, EXPRESS-PLUGIN
  express/
    lib/
    test/
    package.json
  express-plugin/
    lib/
    test/
    package.json
CONNECT, CONNECT-PLUGIN

然后单击/双击CONNECT, CONNECT-PLUGIN分隔符将切换为将其作为活动工作区。对于需要处理多组项目的人员，这将允许在工作空间之间轻松切换。我不建议将它们全部用于搜索和SCM，而当前工作空间是当前扩展的工作空间，将保留这些内容。

然后，可以按照第一组中的建议突出显示根文件夹，并且将鼠标悬停在这些文件夹上时，可以使用新的文件/文件夹图标。

有关设置JSON的一些反馈，对于工作区设置来说，类似于以下内容可能会很有用：

workspaces: [
    {
        name: "Express Project",
        root: "file://C:/workspace/",
        folders: [
            "./express/",
            "./express-plugin/"
        ]
    }
]

因此，然后root成为打开文件夹的源，而不是路径，但是根本身并未打开，仅打开了每个文件夹。然后，您没有“主文件夹”，但仍保留相对文件路径。这是假定您可以通过UI打开一个预定义的工作区，而不是用它打开根文件夹和所有其他文件夹。然后，该名称可以用作分隔符，以防止大量的文件夹名称过长或缩短。

BTMorton 于 2017-06-04

如果选择了“每个根文件夹一个部分”解决方案，那么我想建议当前可见的根文件夹“粘在”侧边栏的顶部，而不是向上滚动到视线之外。只有随后的根文件夹到达侧边栏顶部时，它才会向上滚动。

2017年6月4日上午6：47，Peter Petrov [email protected]写道：
由于@maddouri列出的相同原因，我更喜欢“每个根文件夹一个分区”的设计。此外，使用了另一种方法（在Atom中）后，从视觉上看，当多个高度分层的文件夹打开并展开时，很难找到新的根文件夹在哪里开始。
-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件，在GitHub上查看，或使该线程静音。

dgileadi 于 2017-06-04

👍2

或者，我们可以采用Sublime，Atom方法，但是更改颜色或以某种方式显示哪个文件夹是根文件夹和/或将其粘贴到顶部。当然，两种方法都不错，但是拥有大量打开的文件夹会减少空间，因为带有刷新的bar，创建新文件等都是可见的，这就是为什么最好不加载bar的原因，但是以某种方式显示哪个文件夹是根。但是，此栏确实非常好，因为查看已打开的根文件夹更加容易，您可以刷新它们并执行栏中包含的其他操作。我们需要查看打开10个文件夹（带和不带栏）时的外观。

svipas 于 2017-06-04

@stevencl感谢您发布这些录音！总的来说，我对该功能的发展方向感到兴奋！谢谢您迄今投入的所有时间和精力。这是我的反馈意见/想法：

我更喜欢第一个在“ EXPLORER”下使用单个文件夹名称栏设计的设计，但是，我担心如果所有文件夹名称都在此处列出，它将很快被截断以便显示“添加文件”，“添加文件夹”等按钮。我想我会在打开多个文件夹时只输入字符串“ Multiple”或类似内容；否则，只有一个文件夹，因此请像今天一样在其中放置该文件夹的名称（并将文件夹根目录隐藏在树中）。
除非有多个打开了相同文件名的编辑器，否则不需要通过在IMO的选项卡标题中附加文件夹名称来消除文件名的歧义。请注意，即使打开一个文件夹，这种情况也很常见。在同一个根目录下的子文件夹中获取多个具有相同名称的文件（例如.gitignore ）非常容易。因此，此设计（在父文件夹名称后）应为IMO的单独功能，并应予以实施。伴随着这一点，我很乐意为https://github.com/Microsoft/vscode/issues/15048找到一个很好的解决方案，因为这会使某些标签标题更长。 :)
对于搜索结果，我认为跨所有根文件夹进行搜索至关重要。可以添加另一个过滤器以将搜索限制到选定的根。显示结果时，查看每个根目录的结果可能会很有用，因此可以选择查看一个附加了根文件夹名称的长列表，或者查看一个分为几部分的列表，每个根文件夹一个。
我感到奇怪的是，您提议将“工作区”添加到__user settings__。我真的希望这能在__workspace settings__中结束。我想您实际上是在说工作空间设置还可以包含新的'workspaces'属性，这很好。工作空间路径可以是相对的也非常好。它似乎根本不属于用户设置。这是一个非常特定于工作空间的功能。嗯，但是现在我知道了为什么它在用户设置中也有效，因为当我希望将HDD上的“随机”文件夹放在一个没有通用根目录的工作空间中时，它为我提供了一种存储这些工作空间的方法。
当将它们存储在用户设置中时，似乎在工作区中迷失的一件事是能够将其他特定于项目的设置归于一个或另一个工作区。例如，如果我有一个工作区，我需要选项卡的大小为2个空格，另一个则必须为3个空格，那么我将无法使用用户设置中的工作空间来做到这一点。我必须在某个位置创建一个文件夹，然后在其中放置一个.vscode文件夹，然后定义.vscode/settings.json ，以便最终使用适当的选项卡大小覆盖定义我的工作区。在这一点上，我正在考虑创建一个新的VSCode Project文件类型来存储所有这些设置，并可以将其作为特殊文件打开，这比必须创建此文件夹层次结构来存储工作区的麻烦要少得多settings.json文件...

stefcameron 于 2017-06-04

在第一种设计中，对于其他文件夹，可以将括号中的路径（相对或绝对）附加到名称中以进行区分。我认为这将是一个简单的解决方案。

gulshan 于 2017-06-05

@stevencl感谢您录制会议。我真的很想参加，但当时还没空😢

我喜欢建议的SCM接口。 IMHO的摘要部分和每个文件夹的搜索”选项卡中使用“每个文件夹一个节”的想法，而不是在每个结果中串联文件夹名称。 “资源管理器”选项卡也是如此。

使用用户设置存储_Multi-Folder_对我来说有点奇怪，因为它似乎并不是用户设置_：微笑：。如果要避免创建新文件并简化在计算机之间传输/同步项目/工作区的操作，为什么不忘了_user settings_并把additionalFolder条目_always_纳入Workspace Settings一部分Workspace Settings 。然后，在打开文件夹时，只需在其中查找.vscode\settings.json文件和additionalFolders条目，以检查是否这是一个多文件夹工作区。 _这与您使用的第二个示例相似，只是缺少了两个git repos_。

SomeFolder.vscodesettings.json

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

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

此外，还支持$ _ ~和$home这样的_user-data_位置，从而使在不同计算机/平台之间共享项目更加容易。

我只漏了一点： API 。扩展将如何与之集成？

感谢您的努力。期待首批内部人发布👍

alefragnani 于 2017-06-05

👍3

感谢您的反馈！我想跟进利用新设置属性additionalFolders实施“多根”的方向，因为我从上面的评论中听到了一些反馈。

首先引入设置的主要动机实际上是为了使事情简单，不引入太多新概念，同时仍然拥有功能强大且支持一些有趣场景的解决方案。以下是一些设计决策和后果：

把事情简单化
我们认为打开文件和文件夹是VS Code的核心。因此，我们不想引入“项目”的新顶级概念。例如，我们认为不需要“打开项目”操作，而是认为项目始终是文件夹，并且可以有选择地关联其他文件夹。在这种假设下，设置似乎是允许这样做的自然方式。每当您打开此文件夹时，都将随之打开其他文件夹。添加和删除文件夹是一个简单的手势，它将直接更新设置。

设置功能强大
将多根设置为设置可以启用许多有趣的方案。例如，您可以自由地将additionalFolders设置放入您的工作区中，并与其他人共享（通过使用相对路径-在视频中显示）。
最重要的是，您还可以自由设置项目的开始方式：例如，在某些情况下，主文件夹与其他文件夹之间没有明确的关系（例如，可能其中一些甚至与彼此）。在这种情况下，您可以创建一个“项目”文件夹，其中仅包含settings.json及其链接到的文件夹：

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

现在，当您打开allMyRandomProjects ，它将根据设置显示文件夹列表。您甚至可以在settings.json中包含一些设置，这些设置应适用于所有显示的文件夹。

工作区切换和多窗口
毫无疑问，我们需要在VS Code中进行更好的工作区切换和多窗口支持。由于我们将多根工作区与使用文件夹的任何其他工作区相同，因此改进工作区切换和多窗口支持将使任何用户受益，即使那些没有利用多根工作区的用户也是如此。
我们将不得不研究更好和更容易的方式来在文件夹和打开的窗口之间进行切换，而这些窗口与多根目录无关。

在我的下一条评论中，我将对所发表的个人评论提供一些反馈。

bpasero 于 2017-06-05

👍4

@borekb搜索将包括限制到特定根文件夹（或多个）的选项，其方式与您现在可以配置搜索以包括特定路径的方式相同。

@maddouri @TurkeyMan @ pesho ， @dgileadi @stefcameron似乎很明显，有些人喜欢一棵树，而另一些人更喜欢浏览器中的多个部分。因此，我们可能最终会对此设置，这两种解决方案都各有利弊，并且应该由用户决定，哪种方案更适合该场景。

@borekb设置的应用方式将根据您是否处于多根设置而有所变化：用户设置始终应用于以前打开的所有文件夹。工作区设置将从主（“ master”）文件夹中提取，并应用于与之关联的所有文件和文件夹。现在，尽管我们可能不支持所有其他文件夹，但您仍可以通过工作空间设置在任何其他文件夹上定义设置。例如，不能在每个文件夹的基础上支持update.channel: none类的设置。我们要做的是确定我们可以在文件夹级别上支持的设置（例如files.exclude ，所有编辑器设置），并进行必要的更改以启用它们。这是我们必须投资的主要工作领域之一，特别是因为扩展也可以定义我们希望在每个文件夹范围内支持的设置。

@BTMorton在我看来，您想要更简单的方法来切换工作区。对于用户可以执行的任何文件夹转换，我们都应该独立于多根目录进行研究。

@stefcameron，我们将保持additionalFolders设置足够开放以最终向其中添加其他元数据。例如，我可以考虑能够为这样的配置提供名称，以便在项目之间切换时按名称而不是按主文件夹进行。

bpasero 于 2017-06-05

👍7

视频中尚未涉及的一件事是扩展如何支持多根文件夹。多根支持（“保持简单”之外）的另一个主要目标是：不破坏扩展

如今，扩展程序具有简单的API，可以访问当前打开的工作空间（ workspace.rootPath: string ）。万一没有打开文件夹，此属性可以是null 。

现在，通过引入additionalFolders设置，扩展程序仍可以依赖于设置的workspace.rootPath属性（如果打开了文件夹），或者不设置（当未打开文件夹时）。由于additionalFolders实际上是一个设置，因此扩展名可以使用我们今天在设置周围拥有的API来自由读取甚至写入此设置。更改此设置时甚至会发出一个事件，从而允许用户动态更改此设置。

读取此设置可以使扩展知道工作空间中的其他文件夹。例如，Travis CI扩展名可以选择显示所有文件夹的汇总状态。

编写此设置可以启用一些有趣的扩展方案：例如，您可以有一个项目管理器扩展，可以动态地向工作空间添加和删除文件夹，因此可以在窗口内进行项目转换，例如，通过选择器UI显示项目列表。

在某一时刻，我们可能会引入一些真正的新扩展API来处理多根文件夹。将其隐藏在扩展读/写设置中有点奇怪。但首先，扩展程序已经可以探索additionalFolders设置，以尽可能利用它。我们还将与扩展作者紧密合作，以了解他们的情况以及如何更好地支持他们。

bpasero 于 2017-06-05

👍3

@bpasero还会在LSP中添加其他文件夹的概念吗，还是VS Code会在每个其他文件夹中仅启动一个语言服务器？

felixfbecker 于 2017-06-05

👍1

@felixfbecker这是我们仍然需要投资和探索的东西，以找到语言扩展的良好解决方案。一旦考虑了用于扩展的其他API，我们还需要考虑这对LSP意味着什么。

值得一提的是，今天您已经遇到了以下情况：用户从未作为工作空间打开的文件夹中打开文件（例如，“文件”>“打开”>“ somefile.xyz”）。理想情况下，即使未打开该文件的文件夹，语言扩展名也可以显示该文件的相同级别的语言功能。

首先，从additionalFolders一个打开文件的行为与打开不在最初打开的文件夹中的文件非常相似。例如，TypeScript可以很好地处理这种情况：它们只是从当前打开的文件中走到找到tsconfig.json文件，然后将其视为项目。查找参考之类的功能可以正常工作：

如果任何语言扩展都可以通过仅从当前活动文件进入而不是强制具有明确的项目上下文而起作用，那将是很好的。

bpasero 于 2017-06-05

@bpasero感谢您的评论。因此，在当前模型中似乎总会有一个“主”文件夹：即使在allMyRandomProjects示例中，该文件夹也基本上是主文件夹，尽管大部分为空。这有一些细微的含义，但是我需要多加思考，以提供有用的反馈。

总的来说，我认为VSCode应该以非常相似的方式支持Monorepo与多个存储库，如上面的评论所示： https :

顺便说一句，您究竟如何定义“根”？如果打开包含子文件夹B和C的文件夹A，与将A定义为path以及将B和C定义为additionalFolders什么不同？ VSCode处理这两种情况的意图是完全不同还是基本相同？（我认为应该是非常相似的经历。）

borekb 于 2017-06-05

@bpasero

首先，从其中一个附加文件夹打开文件的行为与打开不在最初打开的文件夹中的文件非常相似。例如，TypeScript可以很好地处理这种情况：它们只是从当前打开的文件开始直到找到tsconfig.json文件，然后将其视为项目。查找参考之类的功能可以正常工作：

但是TypeScript不使用LSP。在LSP中，语言服务器具有rootUri ，例如PHP将使用此rootUri扫描需要索引的文件。它没有tsconfig.json之类的文件来表示“项目”。因此，如果有一些文件不是通过didOpen打开的，但也不是在rootUri ，那么这些文件就不会考虑代码智能，因此，我的问题是LSP是否会为此扩展。

felixfbecker 于 2017-06-05

👍1

只是澄清一下，如果文件不存在，打开多个根会创建文件./.vscode/settings.json吗？
到目前为止，从我在这里所读的内容来看，好像我们在说。

我知道为什么避免添加项目的概念很有用，但是使工作区的保存为可选可能是一件好事-即使在这种情况下，“保存”仅意味着在根文件夹中创建一个设置文件。

我认为，如果用户没有打开该文件夹并创建了一个设置文件，却没有关注该线程的用户可能会感到惊讶。我相信大多数用户希望打开文件夹是只读的。

saborrie 于 2017-06-05

👍1

感谢大家的反馈，这非常有用。

@saborrie-有关在添加文件夹后创建设置会给人们带来多大程度影响的好问题。我们将需要进行调查，以了解是否是这种情况（显然对于那些没有关注此主题的人:-)）。

@borekb-我们讨论了您提到的场景（打开一个包含一个或多

我也会对其他人对此有兴趣。

stevencl 于 2017-06-05

👍2

@borekb带来了一个好点，我也要说，如果您打开一个包含多个git存储库的文件夹，我们的SCM视图应该能够显示与通过以下方式显式设置的视图相同的视图additionalFolders属性。我认为我们可以开始使用设置了additionalFolders设置的文件夹来探索UI的演变，然后将其扩展到更多用例。另一个有趣且相关的场景是我们选择如何在存储库中显示子模块。

我还认为，一旦我们解决了随之而来的挑战，最终我们将希望在任何文件夹层次结构级别上支持.vscode设置。

在谈论多根目录时，我不会谈论主从关系，因为大多数UX都会将主文件夹与其他文件夹等同。主文件夹实际上只是其他文件夹设置的容器，它将成为全局工作区设置的主要驱动程序。为了向后兼容，它也将作为rootPath发送给扩展。

@felixfbecker表示我仅打开项目的一个PHP文件时不能执行“查找参考”或类似语言的功能，我需要打开该文件夹才能获得这些功能吗？我对PHP并不了解，但是如果有跨文件依赖性的概念，那么我将无法仅从单个文件导航到另一个PHP文件，我需要首先打开该文件夹吗？

@saborrie在添加文件夹时，默认情况下不会添加工作区设置。我们决定将此设置为用户设置的原因之一是，使用多根设置不会使工作区变得“肮脏”。可以将此设置放入工作空间，但是您需要手动进行。默认情况下不会发生。

bpasero 于 2017-06-05

@bpasero好的，坚持保存到用户设置而不是工作区设置中可以防止弄脏工作区文件夹-我猜它仍然可以保存，但是要求用户显式执行保存操作，是吗？

这给我留下了两个后续问题：

1）当用户打开在工作区设置中定义了additionalFolders的工作区时会发生什么？这会同步到他们的用户设置中吗？并且如果它存在于用户设置工作空间列表中，它将覆盖该工作空间根目录的条目吗？或相反亦然？

2）与最初避免在两个JSON设置文件之一中存储工作空间相比，将此工作空间列表放入用户设置中是否是更好的选择？在当前的单文件夹系统中，当从File > Open Recent菜单项重新打开文件夹时，会记住以前打开的选项卡-据我所知，这不会存储在任何用户中可编辑的设置文件，在用户显式保存附加路径之前，不能以相同的方式存储附加路径吗？

saborrie 于 2017-06-05

-对不起，我使用了Google翻译-

好吧，我遍历了版式，（是的-在理解英语方面有些困难）。那不好意思了...

我不喜欢@maddouri提出的布局，主要是由于本期中发现的问题（＃25352，＃25354）。我认为，即使您必须使用键盘访问显示模型中的文件夹，也会更加复杂。

我更喜欢这种模型，根据这个想法，我可以使用箭头键在不同的项目文件夹之间导航，如果需要在主文件夹中创建文件夹/文件，则可以使用键盘上的菜单键夹。

explorernew

和/或带有新文件，新文件夹更新和全部折叠的选项。

explorernew2

至于显示在顶部的标题，我更喜欢将焦点集中在当前文件及其所在的文件夹中，或者而不是显示所有打开的主文件夹以及当前文件，类似于此图像。

explorernew3

还有一个问题：开放编辑器还会存在吗？

Tekbr 于 2017-06-05

@bpasero

这是否意味着仅打开项目的一个PHP文件时我无法执行“查找参考”或类似语言的功能，我需要打开该文件夹才能获得这些功能？我对PHP并不了解，但是如果有跨文件依赖性的概念，那么我将无法仅从单个文件导航到另一个PHP文件，我需要首先打开该文件夹吗？

没错，如果您仅打开一个文件，则无法转到未打开的其他文件中的文件，而只能指向rootUri 。那是因为在PHP中，每个文件都可以在全局名称空间中转储符号，而名称空间实际上只是类的名称前缀。对于名称空间和类名与目录和文件名的对应方式没有任何限制（仅某些约定），并且像TS中一样，没有导入语句，只有名称空间别名。加载类在运行时通过注册的“自动加载器”进行。这意味着对于要定义的语言服务器，可以在任何文件中定义符号。因此，语言服务器将在启动时rootUri所有文件建立索引，然后使用索引来回答请求。起作用的是，如果您打开了一个项目，并创建了一个未保存的新文件-您将获得情报，因为您通过textDocument/didOpen获得了rootUri和新文件。但是，将不会考虑未在rootUri之下的未打开文件中定义的任何符号。

felixfbecker 于 2017-06-05

👍1

@saborrie工作区设置将覆盖用户设置，与以前相同。工作区中的additionalFolders设置始终优先。但是，鉴于此设置的性质，只有在工作空间中指定了此设置后，您才可以覆盖当前打开的文件夹的extraFolders（在视频中， path: "." ”作为“ master”拥有

与我们讨论的一个选项类似，将其作为UI状态存储与打开多少个选项卡类似，但是我们发现与设置相比，它没有很多优点。原因如下：

这是不可共享的（既不能通过工作空间设置，也不能通过设置同步扩展名）
这不是扩展程序今天可以轻松访问的东西（设置API存在，UI状态API不存在）

您是否有特定原因不想在设置中使用此设置？

@Tekbr是的，“打开编辑器”将像以前一样工作

@ felixfbecker ，PHP扩展能够轻松采用rootUri: string[]类的东西吗？还是您想让PHP语言服务器为每个打开的文件夹多次启动（例如VS Code将在打开的文件夹级别将多路复用到N个语言服务器？）

bpasero 于 2017-06-06

@bpasero PHP可以很容易地与rootUris: string[] 。其他语言服务器可能不会。生成多个语言服务器意味着每个文件夹都可以隔离工作（在它们之间没有跳转到定义的所有引用）。也许一种方法是使用新的ServerCapability来决定VS Code是否产生一个或多个语言服务器。

felixfbecker 于 2017-06-06

👍3

我喜欢附加文件夹设置的概念。对我来说，只有一个根文件夹就足够了。如果要在关联项目上具有完整的开发功能，则可以打开一个新的vscode窗口。

我从其他文件夹中需要的只是功能有限。例如，我可能希望关联项目中的符号定义可在根项目中使用，但不需要或希望能够对其重命名或在其他文件夹中找到它的所有引用。

bmewburn 于 2017-06-07

@bpasero我只是提倡考虑使设置中的工作区创建为可选（和选择加入）。从本质上讲，不是在用户添加文件夹时自动更改设置，而是以UI状态开始它，然后允许用户以某种方式将其保存到设置中。也许还可以选择是进入工作区设置还是进入用户设置。

我并不完全反对完全存储在设置中，我只是在质疑我不使用UI状态的决定，以防万一它被忽略了。

saborrie 于 2017-06-07

@bpasero @saborrie如果我们沿着那条路线走，那么我会补充说，当提示您保存到设置时，应该有一个选项“记住我的选择”（将工作空间保存为设置，无论是用户设置还是项目设置）。我会很失望地打开一个VSCode窗口，加载几个文件夹，按照我想要的方式正常工作，然后重新启动或崩溃，并且我丢失了该文件夹组合的整个配置，因为工作区从未保存过到磁盘。

stefcameron 于 2017-06-07

第396章（评论）

@Tekbr是的，“打开编辑器”将像以前一样工作

感谢您的回复，@ bpasero。

Tekbr 于 2017-06-07

TL; DR：在适当时使用树状视图，而不是将根名称附加到每个项目中。

几件事，我真的不喜欢您将文件夹追加到末尾的方式，我真的希望它是一个选择，因为我可能希望拥有这样的express\.editorconfig和express-plugin\.editorconfig这样也许您可以提供以下选项： editor.tabName: "${root}\${filename}"

我想在视频中提到的另一件事是，您要在根部上涂上颜色以匹配选项卡，因此👍。

搜索：

在Search视图中，我实际上认为您在体验方面犯了错误，在我看来，它应该显示为树状，如下所示：

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

原因如下：

无论文件名的长度如何，您都可以轻松查看文件在哪里。
您可以折叠不想看到的根。

我认为它也更适合您应用于Explorer 。

任务：

对于Tasks我希望有这种看法：

express
    Compile
    Run Tests
express-plugin
    Compile
    Run Tests

几点：

我认为您不应触摸/更改文件夹名称，这意味着“ express-plugin”的显示应与Explorer显示的完全相同，而不是“ Express Plugin”。
也可以通过键盘在任务之间移动，从而忽略选择根，因此，如果在示例中从express\"Run Tests"下移，则下一个要选择的项目是express-plugin\Compile反对express-plugin

ps尚未看完整部视频，但这些只是我想到的事情。

eyalsk 于 2017-06-09

👍3

如果您包含在工作空间中的所有根文件夹都具有相同的名称怎么办？
例如

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

然后，您将拥有一个包含以下内容的工作空间：

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

按照在工作空间中包含文件夹的_sublime_方式，每个虚拟文件夹的根都有：

路径
名称（可选）-这是文件夹的名称（如果已排除），但可以显示为任何内容
文件/文件夹的排除过滤器

请参阅注释https://github.com/Microsoft/vscode/issues/396#issuecomment -283541760（上方），以获取与这种处理方式相关联的元数据的示例。

doublehelix 于 2017-06-09

👍3

我想知道这个功能还处于开发阶段吗？

ifzm 于 2017-06-09

👎8

@ifzm是的，如果您阅读了最新的（2017年5月（1.13版））发行说明，您会知道他们正在积极地进行开发。

eyalsk 于 2017-06-09

@eyalsk对不起，我没有仔细看，这是一个令人兴奋的功能：D

ifzm 于 2017-06-09

尽管我了解保持简单的愿望，但我对additionalFolders概念并不感到疯狂。

在我看来，一组文件夹中的一个将存储“工作区”的配置对我来说很奇怪。

想象以下根文件夹：

网站
api
移动

...哪个文件夹应具有additionalFolders设置？为什么？

我更喜欢工作空间/项目经理的想法，其中的设置存储在共享/常规位置。从UX的角度来看，我真的不认为这很复杂，并且现有的workspace术语可以重复使用/扩展。

无关：我完全同意@eyalsk关于嵌套列表（和制表符命名）的评论。

glen-84 于 2017-06-09

❤3 👍1

在这种情况下，@ glen-84可以在磁盘上自由创建第四个文件夹“ my-mobile-website-project”，该文件夹具有此设置并链接到所有其他文件夹。

bpasero 于 2017-06-10

@bpasero我理解这一点，但这实际上只是一个hack。

glen-84 于 2017-06-10

详细说明：

我正在忙于website ，并决定要对api进行一些更改。如果我单击Add Folder ，它将把api与website关联，这样将来打开website将打开api也一样我需要了解它是如何工作的，并且在这样做时，我必须打开一个单独的VSC实例，创建一个名称适当的空文件夹，向其中添加两个“项目”文件夹，然后关闭该初始实例。

相反，我可以简单地使用Add Folder ，它可以（可选地）提示我输入工作区名称，以供将来同时打开两个文件夹时使用。

workspaces.json （示例）

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

我只是觉得自己更灵活而又不那么尴尬。

glen-84 于 2017-06-10

👍3

@ glen-84了解。与您提出的解决方案一起使用会使使用VS Code变得更加复杂，这就是我们选择反对这种概念的原因。主要原因是突然之间不仅有“打开文件”和“打开文件夹”，而且还有“打开项目”。在不引入新概念的情况下，保持原语是更直接的方法。

就是说，对于您建议的方案，我们现在为支持多个文件夹所做的所有工作都是不错的工作。如果我们想支持您的方案，那么到达此步骤的步骤就少了很多，因为UI已经适合它。我还可以预见，扩展可能会引入这样的工作空间概念，而我们只是添加了必要的API来支持它。

让我们首先在没有引入新概念的情况下正确使用UX，然后再考虑围绕多文件夹的其他方案。首先要看的东西很多（扩展，设置，SCM UI等）。

bpasero 于 2017-06-10

您提出的解决方案使使用VS Code更加复杂

我不同意这一点。如果用户对可选的“打开项目”（或工作区）功能感到困惑，那么他们很可能会与VSCode中的许多现有功能相混淆。从用户角度来看，这并不复杂（如果任何人不同意，请这么说）。

我还可以预见，扩展可能会引入这样的工作空间概念，而我们只是添加了必要的API来支持它。

该扩展名已经存在，并且已经被提及多次。作者甚至具有开放的票证跟踪多文件夹支持。该扩展程序的安装量为370k +，评分为4.7。即使使用命令面板的UI过于简单，通过注释判断也几乎没有混淆的迹象。

让我们首先在没有引入新概念的情况下正确使用UX，然后考虑围绕多文件夹的其他方案

这很公平。无论哪种方式，都是在同一个窗口中支持多个根文件夹–稍后可以解决管理这些文件夹组的实际方法。

您是考虑创建公开民意调查来收集用户对此主题的意见（我知道YouTube视频，但我指的是这方面），还是已经决定采用additionalFolders概念？

glen-84 于 2017-06-10

👍8

我同意@ glen-84。我不了解复杂性问题。是的，它可以使其更复杂，但这是一个代码编辑器。我认为有95％的程序员正在使用它，这很容易理解项目的想法。每天都在混淆人们，因为每天人们都没有使用它。

尽管扩展在某种程度上是一种解决方案，但与本机实现的增强功能相比，扩展也属于第二流（即，不能向菜单添加选项，只能添加命令调色板等）。

pltrant 于 2017-06-10

👍3

@ glen-84已根据开发团队的想法，我们做过的用户研究（这2个视频）以及我们在此问题中获得的反馈，决定采用additionalFolders设置。

@pltrant使得使用多根目录变得更加复杂，因为您必须不断考虑打开文件夹或打开项目。如果选择的条目是一个文件夹或项目，则诸如“最近打开”之类的事情突然需要更多的注意，或者更糟的是，您甚至会有2个选择器，并且必须决定使用哪个选择器。

我不确定设置会有多复杂。基本上，您不必关心设置，只需在设置中添加和删除文件夹，设置就会在后台更新。我认为，在大多数情况下，您永远不会考虑这种设置的价值。

bpasero 于 2017-06-10

👍2

@ glen-84关于您的一个具有3个相同重要性文件夹的项目示例，我认为哪个文件夹应包含additionalFolders设置应取决于相关性。如果API文件夹不依赖于其他项目，则在打开它时，应将其作为一个文件夹打开，并且不应包含任何其他文件夹设置。但是，当您打开移动文件夹时，我想它与API文件夹有关。因此，您可以在移动文件夹中添加设置，以便在vscode中打开该API时将其作为其他文件夹打开API。网站也是如此。如果依赖于api，请在此处添加设置。如果不是，则不需要任何设置。

我认为不会递归或级联其他文件夹打开。我也喜欢扩展的想法，可以阅读其他项目格式，例如Visual Studio解决方案，并建议/放置其他FolderFolder设置。而且，您始终可以打开所有公用的父文件夹。

gulshan 于 2017-06-10

👍2

@stevencl观看了两个视频。

消除歧义的备选方案2似乎最为清楚。看起来这可能是可折叠的（即树的根之一），这将允许一次看到许多项目。如果您需要样机，请告诉我。
从屏幕空间的角度来看，备选方案2更有效。您不会在顶部重复相同的信息（项目名称），就像在选项1中那样，然后显示在每个项目的根目录中。
搜索结果和Git的行为方式...可折叠树。结果将被分组（连同状态）在其适当的标题下。我想如果您想要一个可导航的摘要（如您为GIT所显示的那样，那将是一个可能存在于搜索（找到的文件数）和项目区域（可以容纳操作按钮）中的选项。

因此，总而言之，我喜欢带有可导航摘要的各个可折叠根目录。替代方案2和此示例的组合

我希望无论您选择什么，您都可以在各种机制中获得相似的体验。您说有两种选择，但实际上有4种，因为GIT和搜索都不同。我同意发表评论的人

回复：共享多项目信息。我认为这将是有用的-一开始您将如何拥有它-我将仅使用gulp任务-或VS Code可以理解的任务。

感谢您为此付出的所有努力。

bkbonner 于 2017-06-10

在＃28344和今年6月的里程碑中，将跟踪多根工作区的实现。

gulshan 于 2017-06-11

❤2 👍2

@gulshan ，

在某些情况下，没有依赖性。例如，如果我正在处理website并决定添加mobile以便同时进行处理。两者之间没有依赖关系，但是现在website成为“父”。如果我碰巧先是在mobile ，那么它将成为父项。这只是任意的。该文件夹也可以用于完全不相关的项目。

无论如何，即使我不一定同意VSC开发人员的决定，我也尊重它。

glen-84 于 2017-06-11

👍3

感谢您的所有继续评论。如上所述，我们正在跟踪问题＃28344。我们将继续努力，尤其是在设计SCM体验时，将考虑这些评论。正如视频中所讨论的和上面多次提到的那样，我们希望在整个体验中保持一致性。

关于@ glen-84，@ pltrant和其他人提出的复杂性问题，感谢详细的建议和响应。我们了解反馈，并将在我们处理此功能时继续对其进行监视。

关于此的讨论确实很有帮助，并为我们当前的设计提供了一些需要考虑的东西。例如，也许我们应该考虑允许用户在将第二个文件夹添加到工作区时选择“主要”文件夹。也许我们在关闭工作区时提示您这样做，也许是一个设置。我们需要考虑很多事情来简化体验。

正如@bpasero提到的那样，我们总是非常不愿意在VS Code中添加新概念（例如项目）。这并不是因为我们认为这会使VS Code无法使用，更多的是更多的概念增加了VS Code的重量或重量，使其感觉更加复杂。这样的概念将是开发人员必须投入的其他资源。

此外，一旦VS Code中包含某些内容，将其删除就变得困难得多（随着时间的流逝，人们逐渐习惯并依赖它）。因此，我们花费大量时间仔细考虑要添加到VS Code中的内容，并且仅在确信添加新概念的成本值得时才添加一些内容。因此，现在我们要确定不添加新概念的多根设计的成功程度。

再次感谢您提供宝贵的反馈。如果没有这样的对话，那么设计这种体验将变得更加困难。

stevencl 于 2017-06-12

👍3

团队中所有人的体贴和反应真棒！非常感谢！

关于复杂性，可能还没有说的是，您仍然在添加一些内容。我认为目前正在讨论这两种选择：

明确的项目。
看起来像普通的多个文件夹，但实际上不是。–一个重要的概念是主文件夹，它涉及诸如rootUrl的扩展名和可能的其他事项（例如，工作区设置继承）。我认为，通常，VSCode用户将需要理解此概念，也许比起将其抽象化来，对其进行明确和预先了解会更容易。

我实际上更喜欢第三种方式，实际上不引入任何新内容，而只是以透明的方式处理多个.git仓库，搜索和任务以及类似的事情-类似于视频的前三分之二建议（我非常喜欢线框）。但是，后来我意识到扩展需要考虑rootUrl ，这可能是复杂的主要原因。

如果不是rootUrl ，那么我将按照线框图中建议的UI更新以及多根工作区的本地持久性开始，与所有其他文件夹在“打开最近”中持久的方式相同。

从我的角度来看，我想重复一遍，理想的状态是VSCode可以与多个文件夹一起使用，而不管它们是否为SCM根目录（monorepo与多个存储库，请参见上文）。我认为建议的线框以及一些额外的核心工作（例如继承.vscode设置）将足以支持“ v1”的多根支持。 IMO，“项目”或“主文件夹+其他文件夹”可能会在以后发布。但是，我要说的可能是rootUrl ，我不确定，我只是想表达我对此的一般看法。

尝试解决这个难题并尽可能保持简单性真是太好了！

borekb 于 2017-06-12

我有一个后端和前端节点项目，并打开了2个VisualCode编辑器，这是一个很大的资源负担。

我观看了两个视频，并同意上面的评论，即这些多个项目与彼此无关。也许一个可能是nodejs项目，而另一个可能是C ++。

我不喜欢其中一个项目成为“主”项目，并添加了其他项目的想法。每个项目应平等且无关。

我希望能够打开一个文件夹，然后打开另一个文件夹（不添加）。就像在视频1中一样，将仅添加该文件夹，并且仅显示根目录（但将鼠标悬停在根文件夹时在工具提示中显示完整路径）。这些项目将完全无关。选择一个或另一个将导致上下文切换。好像我在两个Visual Code实例，设置，配色方案和其他实例之间切换。

保留这些多个项目的方法是将其保存为新项目文件，该文件引用其他两个项目，但不修改两个项目本身中的任何一个。换句话说，这两个项目保持独立，自给自足，并且不知道引用它们的第三个项目（设置文件）。

一旦保存/创建了第3个文件，就应该可以创建覆盖项目A和项目B中的设置的设置。未创建的设置将再次取决于活动项目。

共享项目时，一个可以共享引用另外两个的项目文件。当文件系统中缺少它们，但包含对它们的github url的引用时，它应询问用户是否要获取它们（默认情况下，作为该主项目文件根目录中的子文件夹，但是用户可以浏览所需的每个位置）。

在多个项目中进行搜索的能力应该是可选的，并且能够同时运行和调试多个项目的功能将非常有用，但是对于第一个发行版来说似乎确实太复杂了，也许这种用例无论如何都需要运行两个实例。至少现在。

这在UI中的外观是第二步，但是从功能上来说，这是我希望它能起作用的方式。我不喜欢将项目A修改为引用B或反之亦然的想法，这就是我所理解的意图。对于敏捷开发人员，如果能在1个窗口中处理2个项目，而不必运行2个实例，那我会很高兴，但目前不超过2个。也许甚至没有第三个覆盖的项目文件，而只有上下文切换。

fipda 于 2017-06-13

👍9

感谢您的持续反馈。有一个明确的主题涉及延迟多文件夹工作区的持久性，直到用户采取某些明确的操作（例如保存）。我们需要对此进行更多考虑，并进行进一步调查。

stevencl 于 2017-06-13

👍3

我还建议开发人员对Eclipse IDE进行了解。
处理此功能，他们很久以前就发现并起作用
大。

2017年6月13日，星期二，9：11 AM，史蒂文·克拉克[email protected]
写道：

感谢您的持续反馈。有一个明确的主题
将多文件夹工作区的持久性延迟到一些明确的时间
用户的操作（例如保存）。我们需要考虑更多
并进一步调查。
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/Microsoft/vscode/issues/396#issuecomment-308110390 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAQsBWywBoe2KQRGuXKHv179MmugstCfks5sDop7gaJpZM4Gm3nX
。

-
丹尼尔·索科洛夫斯基
技术架构师

稳定技术集团有限公司
电话：+1（613）634-7410
http://www.stantive.com

保密通知：
传输的信息仅用于个人或实体
可以解决，并且可能包含机密和/或特权
材料。任何审查转播或其他用途
由人员根据此信息采取任何行动，或
禁止除目标收件人以外的实体。如果收到
这是错误的，请立即通过电子返回与发件人联系
传输，然后立即删除此传输，包括所有
附件，不得复制，分发或公开。

danielsokolowski 于 2017-06-13

👎6

硕士项目
我反对拥有MASTER项目。使用不同的微服务时，上下文切换经常发生。这适用于Linting和SCM的以下几点。

工作区的持久性
我认为在第一次迭代中，我们不必保留工作区。在引入任何设置或持久层以最大程度减少任何类型的复杂或破坏性迁移之前，我更喜欢在此功能的一个或两个版本上进行迭代。

整理/设置
应将项目特定的衬布命名为对应目录中文件的名称空间。例如，项目A使用更漂亮，而项目B使用标准。两种上下文之间的切换应该是无缝的，并且不会相互冲突。

搜索
喜欢这一线框图，其中搜索结果遍及所有项目并按项目排序。

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

_Project B_
file3: matched substring
file4: matched substring

单片机
在这种情况下，我更倾向于显示每个scm更改的按项目细分。

_Project A_
file1: added
file2: removed
...

_Project B_
file3: moved
file4: added
file5: added

我觉得这些方法更加透明和直观。

saada 于 2017-06-14

👍4

共识（基于最近的评论和其他问题）似乎与additionalFolders的想法至少在初始版本中。

虽然我知道已经做出了决定，但是您是否考虑尝试将这一功能实现为一组API，同时将持久性留给以后的迭代？因此，用于添加/打开文件夹以及对资源管理器，搜索，任务和SCM视图的更新的API均支持此功能。

您已经讨论了从产品中删除某些东西有多困难（如果某个项目/工作区概念因某种原因失败了），但是现实是，这对additionalFolders概念同样适用（如果不是更多的话）。

将additionalFolders和“ projects / workspaces”都实现为扩展，将允许您收集使用情况数据而无需提交单个模型。这些扩展之一（或混合解决方案）可以稍后集成到产品中。

glen-84 于 2017-06-14

👍4

Mac OS上的环境问题是否已解决？我仍然无法使用Homebrew npm等，而无需通过code从命令行打开VSCode，这肯定会对多根支持造成严重破坏吗？

cliffrowley 于 2017-06-15

😕1

是的，这对我也是必须的。我不了解人们的问题。这可能不是一个人的工作方式，但这并不意味着另一个人首选的工作区管理的有效性较低。我只是讨厌“为什么要这么做？”的答案。而不是“让我们弄清楚如何添加世界上所有其他代码编辑器都具有的功能”。

我想回到原子。

akutz 于 2017-06-16

😕1 🎉1 👎1 👍1

@saborrie https://github.com/Microsoft/vscode/issues/24961 （在Insiders和常规版本中都遇到相同的问题）。如果我可以帮助调试，那我就是游戏。

cliffrowley 于 2017-06-16

@akutz这些人在设计一个体面的多根系统上付出了很大的努力，他们甚至放了设计会议的视频（在最新的发行说明中）。即将到来，但他们正在确保正确无误:-)（https://code.visualstudio.com/updates/v1_13）

cliffrowley 于 2017-06-16

嗨@cliffrowley ，

很高兴听到。我直到最近才一直在使用VSCode，因为我一直在使用Atom（在此之前还使用Sublime）。最近，Atom出现了问题，在Reddit线程中，我看到VSCode实际上是一个不错的选择。因此，令我惊讶的是它不支持基本功能。

akutz 于 2017-06-16

只是在这里堆-这确实是让我不考虑全职从IntelliJ / WebStorm切换到VSCode的唯一功能...主要是因为，如前所述，我整天都在使用分布式架构，并且需要集成多个Git管理给我的编辑（因为我太懒了😆）

我爱你们，所有人都在为此工作，我迫不及待地想看到它的实际效果。

ericnograles 于 2017-06-23

😕3 👍3

我喜欢vscode，但是这种“缺失的功能”使我无法从原子完全转换为vscode

faabianr 于 2017-06-28

👍4 👎3

早期版本已经在Insiders内部。去实现它（梦想）;去得到它（东西：）

kurtextrem 于 2017-06-28

👍11 🎉9

+1需要此功能

timbioz 于 2017-06-28

👎9

第一个预览版非常好！
我什至开始正确测试之前已经存在一个小问题...
当我从两个不同的项目中添加两个具有相同名称的“根”文件夹时，没有什么可区分这些文件夹的。

例如我添加/dev/www/myproject/src ，然后添加/dev/libraries/mycomponent/src
我只看到两个名为src根文件夹。

> src
> src

我相信我们需要一种更改根文件夹的显示名称的方法。
然后将显示：

> My Project (/src)
> Component 1 (/src)

有什么想法吗？

doublehelix 于 2017-06-29

当您打开两个具有相同名称的文件时，VSCode会显示部分文件夹名称，这也可以用于文件夹吗？

cecilemuller 于 2017-06-29

@doublehelix我们最近讨论了此问题，但没有任何地方跟踪该问题。我创建了https://github.com/Microsoft/vscode/issues/29871 ，谢谢thanks

Tyriar 于 2017-06-29

@Tyriar我真的觉得搜索功能至少可以说是令人困惑，并认为它应该显示与我之前说过的Explorer显示的结果类似的结果。

我不知道你们是否看过我和有些人说的话，还是会有更多变化，但是我个人不喜欢每次都添加根名称而不是对树中的东西进行排序的方式尽可能的类似视图。

eyalsk 于 2017-07-01

@eyalsk这是一个正在进行的工作，我将在7月查看更多搜索结果：＃29977

roblourens 于 2017-07-01

👍2

vscode项目基于文件夹。
因此，您可以分别配置每个项目的配置，并且可以直接使用集成的Git，也可以直接使用。

lvxianchao 于 2017-07-06

PyCharm：heart：：heart：：heart：

sxslex 于 2017-07-06

👎24

+1

braga-bruno 于 2017-07-07

👎25 😕1

亲爱的VSCode小组，我要向您表示赞赏。
最终，由于多根工作区已落入“内部人员”内部，因此我能够放弃Atom！
两年以来，在多根工作空间中进行搜索时，Atom不尊重.gitignore等，因此您从一开始就正确理解了这一点！

是否在另一个问题中跟踪了工作区的持久性？

crunchtime-ali 于 2017-07-12

昨天，VS Code团队发布了具有多根工作区功能🎉的VS Code新版本。

这项工作的结果就是我们所谓的“最小可行产品”（MVP），可以在多个根文件夹工作区上进行测试。

实际上，仅可从Insiders构建中获得，因此您可以在此处下载VS Code Insiders

文件管理器

搜索

DannyFeliz 于 2017-07-12

👍34 🎉17 ❤1

假设每个添加到工作区的文件夹都是一个单独的git存储库-当前版本的Multi Root Workspaces是否可以处理这些存储库的不同源代码控制？

Weyzu 于 2017-07-13

@Weyzu我们正在努力在这个里程碑为多根方案采用SCM。我们最初的想法是，SCM视图需要变为多存储库感知的，这不一定与资源管理器和搜索中的多文件夹感知相同：当您在VS Code中打开单个文件夹时，您可能已经在其中拥有多个存储库。我们认为SCM视图应该以一种很好的方式显示这些存储库，以便您可以看到每个存储库的传出/传入更改以及能够从每个存储库提交文件。

结果应该为多根方案以及一个根中包含多个存储库的单根方案提供更好的体验。

bpasero 于 2017-07-13

👍8 ❤4

结果应该为多根方案以及一个根中包含多个存储库的单根方案提供更好的体验。

优秀的方法，你们真棒！

borekb 于 2017-07-13

@bpasero太棒了！我一定很想看到你们的想法。 IntelliJ / WebStorm具有类似的功能，它可以自动检测Git根并将其适当地排列在右下角，我个人很喜欢使用它。

你们是在按照这些思路或更复杂的思路思考吗？

ericnograles 于 2017-07-13

我们仍在为此选择用户体验，并将让您及时了解结果。

bpasero 于 2017-07-13

虚拟文件系统根目录不能在这里工作吗？它可以有效地充当VFS根目录，而该根目录是多个不同路径的父目录。

akutz 于 2017-07-13

我想对多根用户的工作进行更新，因为今天是第一天，我们修订后的多根用户体验发布了内部发行版，许多习惯了“旧”行为的人可能会感到困惑。

旧解决方案的缺陷
多根目录的旧解决方案将引入新设置workspace （进入全局settings.json ），该设置允许将其他文件夹添加到单个根文件夹。如果您没有注意到，则设置看起来像这样：

{
  "path to folder": [
      "additionalFolder1",
      "additionalFolder2"
   ]
}

我们将此解决方案称为带有其他文件夹（“详细信息”）的“主”文件夹。

这是最简单的解决方案，没有引入很多新概念，但也存在缺陷：

您永远无法再将主文件夹作为单个文件夹打开，因为设置仍然存在
您无法从资源管理器中删除主文件夹
主文件夹中的某些设置将应用于所有其他文件夹
您的设置被多根配置文件污染
很难允许同时打开几个文件夹（例如，当您打开3时，我们应该使用哪个主文件夹？）

我们的解决方案
我们认为多根方案需要一个更明确的工作区概念，因此在当今的内部人中，您会看到一些新的UI弹出：

这个想法是，多根工作区需要创建显式操作。就像您可以处于空工作空间（未打开文件夹，紫色状态栏）或处于单文件夹工作空间（浅蓝色状态栏）一样，您也可以处于多根工作空间（深蓝色状态）酒吧）。在VS Code中打开工作区的第三种方式允许您拥有任意数量的文件夹。这些工作空间可以保存到文件（例如myWorkspace.code ）中，还可以包含工作空间设置。但是，只要您不想保存它们，就不必强迫它们保存，它们将显示为“无标题的工作区”。

要打开工作空间，您可以打开保存的工作空间文件或从最近打开的列表中选择：

这些都是非常年轻的代码和非常年轻的UX，因此请期望在接下来的几周中进行一些更改。我们知道仍有一些事情需要解决（例如，如何使从单文件夹到多文件夹的过渡更加平滑）。

根据反馈，今天已经进行的一些更改将在明天的内部发布中生效：

将.code重命名.code-workspace作为工作区的扩展名
具有文件夹和工作空间的统一列表（例如，在“文件”>“打开最近的文件”中），而不是区分文件夹和工作空间

敬请期待更多more

bpasero 于 2017-07-13

👍21 🎉7 ❤5

最重要的是，我们现在每个项目文件夹都有一个.vscode文件夹，其中包含文件settings.json 。该文件可以包含以下内容：

// Place your settings in this file to overwrite default and user settings.
{
      "editor.wordWrap": "on",
      "files.autoSave": "onFocusChange",
       "editor.fontSize": 15
}

这里的问题是，当我们要与同一项目文件夹中服务器上的多个用户（不同的RDP会话）一起使用时，我们共享相同的设置。这可能不是预期的行为。我可能希望字体大小大于同事的字体大小。

因此，我认为，您还应该考虑到不同的用户可能正在使用相同的文件夹，但是在settings.json使用不同的设置。

DarkLite1 于 2017-07-13

👍1

@ DarkLite1您提出了一个好观点。在针对多根目录的设置设计中，我们尝试确定每个文件夹可以支持的设置和不支持的设置。通常，我们说针对每个文件夹都支持针对编辑器或特定资源的设置，因为可以从哪个文件夹中打开编辑器。其他不支持的设置更多是围绕工作台自定义（例如，是否显示状态栏）。

您的示例与editor.fontSize设置有关，即使在多根工作区中，我们实际上也支持每个文件夹。我认为这可能是一个有效的方案，即用户希望为包含大量降价文档的文件夹设置更大的字体（甚至可能使用其他字体？）。因此，我认为在多根环境中，我们也不应阻止对每个文件夹使用此设置。

如果您想将editor.fontSize保留为个人工作区设置，那么我认为不应将其签入存储库。

使用新的工作空间概念，您可以执行以下操作：

文件>工作区>新工作区
选择你的文件夹
打开工作区设置
更改editor.fontSize: 15

从那时起，您的工作区将带有此设置，但您不会将其强制给其他任何人。

bpasero 于 2017-07-13

👍2

从UX角度来看，如果可以将文件夹拖放到VS Code窗口中而不必先明确创建工作区（这是我一直在Sublime中经常做的事情），那将很方便。我总是同时从事多个项目，并且根据我要从事的工作，每天都会有不同的项目（重叠）。

工作区会引入一个并非我的工作方式所固有的概念，而且我不得不跟踪不同的工作区配置（据我了解），这听起来会在我的项目文件夹中造成一些配置混乱。

此外，我认为如果要说搜索，配置等默认情况下是全局的（适用于所有打开的文件夹），我会为很多用户说话-尽管如果我可以选择在文件夹中本地搜索（我总是在Sublime中发现这很棘手）。

SanderMertens 于 2017-07-13

👍2

@SanderMertens您可能已经错过了，但是@bpasero写道；

这些工作空间可以保存到文件（例如myWorkspace.code）中，还可以包括工作空间设置。但是，只要您不想保存它们，就不必强迫它们保存，它们将显示为“无标题的工作区”。

现在，我不确定您是否可以拖放文件夹，但是从我得到的信息来看，人们将能够在不创建工作空间的情况下打开任意文件夹。

eyalsk 于 2017-07-14

我等不及要在稳定版本中包含此功能。

好极了！ 😄

alvincrisuy 于 2017-07-14

当前，您无法将文件夹拖到资源管理器中以添加它，但这已在我们的积压中。这种交互的复杂之处在于我们不知道用户的意图：在窗口中打开文件夹还是将其添加到工作区？

与其他编辑器相比，当前从1个文件夹过渡到许多文件夹是一个更为明确的步骤（您需要通过File> Workspaces> Save Workspace并选择所需的文件夹）。为什么要暂时保持当前行为直到多根稳定之前，有两个原因。主要原因是多根是我们所有扩展的重大变化。尽管资源管理器可以工作，并且您可以搜索所有文件夹，但是大多数扩展在采用新的多根API之前无法正常工作。因此，我们不希望一开始就很容易偶然地输入多根目录。进入多根工作区是一种明确的用户姿态，在这种模式下，我们可能要引起人们注意某些扩展尚未起作用的事实。

另一个原因是工作空间设置：想象一下以下流程：

您从1个具有工作空间设置的文件夹开始
您添加了第二个文件夹（假设此方法无需上下文切换和窗口重载即可使用）
您打开工作区设置
=>多根目录中的工作空间设置现在存储在文件夹之外的某个位置，因为您可以有多个
=>我们可能需要询问用户是否要将工作空间设置迁移到该新位置

因此，无论如何，进入多根目录目前不是轻量级的操作。当尘埃落定并广泛采用多根技术时，我们可能会重新审视此问题，但目前我们认为此模型更好，并且可以避免挫败感。

bpasero 于 2017-07-14

👍1

@bpasero我认为默认情况下，一旦您将文件夹拖到资源管理器中，它就不应自动保存到工作区中，即使可能存在该文件夹，这也应该是一个明确的操作，即用户单击他/她所在的文件夹拖动，然后将其显式添加到工作区中，如果您没有不相关的文件夹，那么明智的做法是提供另一种操作，以一次保存所有这些文件夹。

eyalsk 于 2017-07-14

这完全取决于一个人要涵盖的用例。我从经验中发现，KISS始终是最好的方法。引入Workspaces听起来很像feature但是真正的好处是什么，缺点是什么？

引入和使用Workspaces时想到的一个缺点是它需要将其数据（设置）存储在某个地方，并且需要用户维护/意识。

假设唯一的目标是使用户能够在一个VS Code会话中使用多个文件夹。没什么，没什么了。

最常见的用例：
没有Workspaces概念。用户只是打开一个额外的文件夹，或者打开任意数量的文件夹，就像在单个文件夹中一样，它们在左侧视图中打开。他希望他的设置在任何地方都一样。不管他的文件在哪里。而且他不希望在项目文件之间出现@SanderMertens ，我以及其他可能的人所表示的VS Code配置文件的混乱情况。

挑战/问题/问题：

为什么会有不同的设置文件？用户设置，工作区设置？它应该恕我直言所有都存储在一个相同的位置。通过优先选择用户的个人文件夹/个人资料，因此系统上的每个用户都可以拥有自己的设置。额外奖励。他们不会使项目文件混乱，多个用户可以做自己的事情。清除个人资料？大！也为VS Code清理板岩。

我认为Workspaces有点工程过度，如果您想要的话：
速度，简单性和可正常使用的编辑器，不会使事情复杂化或理解多余的概念。如果Sublime或其他编辑者的用户未在工作流程中使用此概念，则应表示对此事有过多的思考。或者这可能意味着发明了其他编辑器也可以实现的功能，但我对此表示怀疑。

很抱歉，这听起来像是咆哮，那绝对不是我的意图。但是我相信我们可以在多根/文件夹访问方面做得更好。

DarkLite1 于 2017-07-14

@ DarkLite1感谢您抽出

我同意您的所有观点，也希望有一个简单的解决方案。工作空间作为一个概念是我们迈向与我们现有模式（工作空间设置，扩展等）一起使用的多根解决方案的第一步。由于这是第一步，因此请注意一些较粗糙的边缘（例如，从1文件夹过渡到N文件夹并不是那么轻巧）。我们的目标是使这种过渡更加顺利，并且不会使其变得比将来需要的复杂。而且，我们也不想强迫用户管理这些工作区（这就是为什么我们拥有“无标题的工作区”，只要打开该窗口就可以使用，而一旦您关闭该窗口就会消失）。

请记住，多根工作区周围有几件事情可能并不那么明显。我希望以下详细说明有助于理解我们的设计过程：

工作区设置
我们确实支持在工作空间文件夹（ .vscode文件夹）中进行设置。尽管某些用户可能不喜欢以.gitignore文件或存储库结尾的这类设置，但许多用户都依赖此功能。我们不能简单地停止支持存在于文件夹中的设置，因为用户依赖它们。现在，对于多根方案，很明显，我们必须找到一个用于工作空间设置的新位置。我们提出了包含这些设置的工作空间文件的概念。只要工作空间没有保存在任何地方，它就会驻留在包含其他VS Code特定数据的文件夹中，并且当您保存文件时，设置将在该文件内。

现在，假设您从VS Code中定义了工作空间设置的1个文件夹开始，并且想要添加第二个文件夹。我们现在应该做什么？忽略第一个文件夹的工作区设置？要求用户迁移设置？我们决定对此进行显式上下文切换，以明确表明打开工作空间将在不同位置携带其自己的工作空间设置。

现在，假设您从1个文件夹转到2个文件夹，然后将工作空间设置移至其他位置。假设您对这些工作空间设置进行了更改。现在您想从2个文件夹返回到1个文件夹，您是否希望将工作空间设置迁移回该文件夹？

另一个示例：从1个文件夹过渡到2个文件夹并配置工作区设置。现在关闭窗口。我想如果您不能以某种方式返回到此工作空间会生气，因为您已经仔细配置了该工作空间的设置。因此，即使您不喜欢工作空间的概念，但为它配置设置后，我仍希望您可以继续使用该工作空间。

我希望这些例子可以使我们更容易理解为什么KISS对我们来说并不像人们想象的那么容易。

扩展名
我们所有的扩展始终针对提供单个工作空间路径的API起作用，因为到目前为止，我们不支持多根工作空间。作为用户，您可能会认为从1个文件夹切换到2个文件夹是一种非常简单且轻便的操作，但是对于扩展来说，它可能意味着很多事情：到目前为止，假设只有一个文件夹的语言扩展突然必须意识到多个文件夹。最重要的是，这些文件夹可以随时动态变化。

引入一个真正的工作空间概念使我们有更多的空间和时间来进行扩展，并帮助扩展程序采用此概念。例如，我们可以禁用尚未采用多根工作区的扩展名，以防止发生奇怪的事情（例如，语言扩展名仅在一个文件夹上起作用而在另一文件夹上报告错误错误）。

让我们先尝试通过这些新的工作区稳定多根支持，然后再回顾一下如何轻量级地进行过渡。一旦我们有了扩展功能，并弄清楚了我们的设置故事，我认为我们可以转向更轻巧的体验。

PS：由于您参考了其他编辑器的多根支持，因此我只想指出，这些编辑器还带有一个工作区或项目概念，您可以将其保存到文件并与他人共享。通常，您不会看到这些概念，因为从1文件夹转到N文件夹是非常轻便的操作。我要说的是，依赖此功能的人们开始迁移到保存的工作区/项目中，作为管理工作的一种方式。例如，除非您保存工作区/项目并关闭窗口，否则所有这些信息都将丢失。

bpasero 于 2017-07-14

👍3 🎉1

@bpasero感谢您与我联系并提供详细的解释，对此我深表感谢。

由于我不完全了解Sublime，因此我自由检查了他们如何处理此问题。您是对的，他们也使用Workspaces ，甚至Project文件。唯一令我困扰的是，它将VS Code文件放在我的项目之间。但是正如您提到的，如果其他人依赖于此，则必须考虑到这可能是最好的选择。我只是想知道为什么这些设置文件不是特定于用户的？我可以想象一个同事在相同的文件夹结构上打开VS Code，但是想拥有自己的设置。

如果Workspaces是前进的方向，而且看起来确实如此，则在打开应用程序时逻辑上将重新加载上次使用的设置。即使这是未保存的Workspace 。我猜，这会使生活变得更简单。

为什么选择VS Code？因为它是跨平台的，所以当我在家中使用Linux而在工作中使用Windows时，它确实可以成为我的默认编辑器！作为额外的奖励，我是PowerShell开发人员，并且对此进行了扩展。所以那里有两个大胜利！最重要的是，在我遵循的Java课程中，Red Hat也对VS Code进行了扩展。因此，一旦您对VS Code有了更多的捷径，就可以全面受益。

该应用程序及其扩展程序在某些时候仍处于beta甚至Alpha状态，但是，出色的工作人员们！真的很感谢您的努力，并看到Insider每天都有进展。继续努力，度过一个愉快的周末。

DarkLite1 于 2017-07-14

👍1

感谢@bpasero的解释，我想我现在更好地了解了复杂性是什么。

一种方法可能是从概念上对待与工作区相同配置的任何项目集。除此之外，只要项目不偏离默认配置，您就可以避免添加.vscode文件夹。那应该：
1）摆脱项目中最混乱的事物
2）在添加项目时防止大多数配置冲突（在简单情况下，将没有配置）

我认为，所讨论的显式工作区概念是解决上述问题的好方法。通过这两个简单的规则，我将人们遇到此问题的用例最小化。

SanderMertens 于 2017-07-14

对我来说，查看线程中的注释以及用例，我将_Multi-folder_和_Workspaces_视为两个不同的概念，也许也应该分别对待。

它不应强制_创建工作空间_只是将另一个文件夹添加到当前窗口。它应该只是将新文件夹添加到树中，并将新创建的工作空间保留为_internal info_。如果用户决定保存工作区，则实际上已创建了工作区。即使我没有保存工作区，在重新打开顶层文件夹时，它也会_记住我的临时工作区_并同时打开其他文件夹，就像今天打开文件夹时会记住打开的文件一样。顺便说一句，我想知道如何在命令行中打开多文件夹。

对于我的用例，多文件夹只是一种在同一窗口中一次查看多个文件夹的方法，而不是_Project Group / Solution_方法。因此，更简单的解决方案是合适的。但我知道其他人如何需要_Workspace_以及自己的设置，例如： thumbsup:。

关于这个新的Workspaces概念，最困扰我的事情（与使用User Settings的第一次迭代相比）与使用Sublime Text时困扰我的事情相同。您_can_保存.code-workspace文件_anywhere_的事实，现在我必须管理一个公共位置来存储它们。恕我直言，它将自动适合以下两个地方之一：

在user-data-dir文件夹中，例如User Settings和Keybindings
在_Top Folder_中

明确地说，我了解其他用户需要的更复杂的工作区概念。我只是想要一种用于更简单的多文件夹概念的简单方法。

alefragnani 于 2017-07-16

👍2

我喜欢这个选项，添加这个选项。
dddsa
因为里面的文件夹不是很令人印象深刻。
default
或添加更改此选项的功能。

gavrilyuc 于 2017-07-17

👍37 ❤2

我喜欢工作区的想法！关于何时准备就绪的任何想法？

EdoBarroso 于 2017-07-26

👍3

在这一点上是否期望左下角的git信息不能准确反映当前关注文件所在的任何回购的git分支？在v1_15发行说明中，我没有看到任何有关“多个git根”的信息。

anyong 于 2017-07-27

👍3

我已经在Insider构建中使用了此功能几天，我必须说这就是我想要的一切。非常干净的用户体验，我迫不及待地将它发布到主版本中，因此我可以将整个团队转换为这个版本。

使用NodeJS并同时打开多个NPM模块时，将所有内容放到一个窗口中的方式可以节省大量时间。

给团队提供了巨大的道具！

hparadiz 于 2017-08-07

👍15 🎉11 ❤8

为什么此功能带有gif和说明显示在我的发行说明中，但在实际的编辑器中不可用？

ShashankaNataraj 于 2017-08-11

内部人员构建的@ShashankaNataraj不是原始构建。如果您仔细看过文档，将会被提及，仅适用于内部人员构建

Jeyanthinath 于 2017-08-11

https://github.com/Microsoft/vscode/issues/28344中捕获了我们正在进行的多根工作的路线图，该路线图将持续到8月，9月甚至十月。

我们将仅在内部人员中保留此功能，直到：

我们可以提供适当的启用多根SCM，调试和任务的经验
我们为随附的并积极贡献的扩展（例如Go）采用了多根API和功能
扩展作者有足够的时间（例如1个里程碑）来采用新的多根API

请理解，由于我们过早赶紧该功能，因此我们希望避免将其稳定发布并破坏扩展体验。

bpasero 于 2017-08-11

👍38 ❤4

感谢您成为专业人士，干得好！

KioriSun 于 2017-08-11

❤1 🎉1

@bpasero我有点担心扩展作者会及时更新插件。他们会收到一些即将来临的特殊更改电子邮件吗？

谢谢

FelikZ 于 2017-08-17

@FelikZ请查看我们的路线图（https://github.com/Microsoft/vscode/issues/28344）。对于9月的发行版，我们计划采用VS Code中附带的扩展，并且在进行此开发时，我们添加了这样做所需的必要API和实用程序。

在9月，这是计划：

bpasero 于 2017-08-17

❤6

今天的内幕更新对.code-workspace文件进行了一些更改，我想在这里进行总结。具有以前格式的现有工作空间将自动迁移到新格式。

旧格式如下所示：

{
    "id": "1500007676869",
    "folders": [
        "file:///Users/bpasero/Development/Microsoft/monaco",
        "file:///Users/bpasero/Development/Microsoft/vscode-distro",
        "file:///Users/bpasero/Development/Microsoft/vscode-docs",
        "file:///Users/bpasero/Development/Microsoft/vscode-extension-sdk"
    ]
}

和新的格式ist：

{
    "folders": [
        { "path": "/Users/bpasero/Development/Microsoft/monaco" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-distro" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-docs" },
        { "path": "/Users/bpasero/Development/Microsoft/vscode-extension-sdk" }
    ]
}

工作区ID
工作空间ID用于将一些事物与工作空间相关联：

所有UI状态（例如，打开的文件）
所有脏文件状态（又名热退出）
扩展状态（如果有）

我们决定从工作空间文件中删除id属性，而是根据磁盘上工作空间文件的绝对文件路径自动计算id 。这有两个优点和缺点，但最终我们认为优点使此方法更好：

奇怪的是，您只需输入另一个值就可以编辑文件中的id
尚不清楚与其他人共享工作区文件时如何对待id （应该更改id吗？ id应该是uuid吗？）
无法复制工作空间文件并在单独的窗口中打开它，您必须首先在复制的文件中更改id
因此，“将工作空间另存为”操作将不得不询问用户副本是否应具有不同的id

这种方法的一个缺点是，一旦移动或重命名工作空间文件，关联的状态就会丢失。脏文件（“热退出”）在重新启动后仍将重新打开，但是它们将在空窗口中打开，并且不再与工作区窗口关联。我们仍然认为我们可以改善此行为，尽管它的行为与当今用关联的UI状态和脏文件重命名文件夹的行为一致。

资料夹
我们决定重新查看folders属性的格式。

我们不再要求您使用资源URI，而只需使用文件路径即可简化编辑
我们将folders属性的条目更改为对象，以便我们可以根据需要将元数据与条目关联（例如，每个文件夹可以具有额外的name属性）

最后，对相对路径的支持也有所下降。您可以输入相对文件路径，它将相对于工作空间文件的父文件夹进行解析。请注意，由于存在错误https://github.com/Microsoft/vscode/issues/33188，我们目前正在对工作空间文件进行更改时将相对路径重写为绝对路径。

bpasero 于 2017-08-28

🎉5

@bpasero太棒了。什么时候可以使用额外的name属性？目前，我的工作区中有两个名称相同的文件夹，这很糟糕。

danilopolani 于 2017-08-29

@DaniloPolani参见https://github.com/Microsoft/vscode/issues/29871

相对路径处理的更新：从今天的内部人员构建开始，如果工作空间文件的位置是目标的父级，我们将把工作空间文件的路径写为相对路径。换句话说，除非我们必须使用“ ../ ”表示法来表示路径，否则路径现在始终是相对的。

由于无标题的工作区始终位于VS Code的数据目录中，因此其中的路径将始终是绝对的。但是，一旦将无标题的工作空间保存到某个位置，我们将尽可能重写路径。

如果您对本次冲刺期间进入的多根工作区周围的更改感到好奇，请查看更新的发行说明。

bpasero 于 2017-08-29

👍6

+1

ulm0 于 2017-09-18

👎24 👍2 ❤1 🎉1

+1

aecorredor 于 2017-09-19

👎19 ❤1 🎉1 👍1

@bpasero恕我直言，UI状态的处理方式（在.code-workspace文件中使用ID字符串，或使用文件路径作为ID）是不够的。
在我看来，重命名.code-workspace文件或其任何父文件夹，或移动它，以及丢失UI状态完全是不直观的。我认为人们不知道它是如何工作的，对于他们失去以前的UI状态以及如何恢复它的原因绝对是一无所知。
那根本不应该与文件系统中文件的绝对路径绑定！

这也适用于UI状态与稳定版本中当前的文件夹路径相关的方式。起初我对此非常困惑，直到我进行了谷歌搜索。

IMO如果仅处理一个文件夹，则UI状态应保存在.vscode文件夹中。如果我们要处理的是多根工作区，则应使用适当的命名约定将UI状态保存为与.code-workspace文件相同的文件夹中的单独文件（或在该文件本身中，尽管混合使用设置和状态可能不是一个好主意）。

如果正确实施，这将允许用户完全访问UI状态，将新的UI状态附加到给定的工作空间（是否为多根用户）等。
我希望能够在不同计算机之间同步UI状态，例如在办公室工作，然后回家，拿起笔记本电脑或其他东西，然后继续我刚离开的地方。
将多个UI状态附加到工作区并在使用不同功能时轻松地在它们之间进行切换（菜单/键绑定/命令/等）也会很棒。可能自动列出.vscode内的不同.code-uistate文件，或根据主.code-workspace前缀或在数组中列出许多.code-uistate文件。

我正在考虑将其作为Sublime Text上项目和工作区的工作方式的扩展。功能相同，设计不同。在这种情况下，VS Code工作空间将类似于Sublime项目，并且不同的VS Code UI状态将类似于Sublime工作空间。

关于此问题：

奇怪的是，您只需输入另一个值就可以编辑文件中的id

是的，完全是。从那里删除ID是正确的选择。

与其他人共享工作空间文件时，如何处理id尚不清楚（应该更改id吗？id应该是uuid吗？）

好吧，如果我们有myproject.code-workspace和myproject.code-uistate则取决于用户决定是否共享其UI状态。无需再思考该ID的含义，它是如何生成的，是否需要成为UUID以避免共享时发生冲突等等。
是否要共享文件夹设置和设置？发送myproject.code-workspace ，无需担心。
想分享一切吗？发送两个文件。

无法复制工作空间文件并在单独的窗口中打开它，您必须先在复制的文件中更改ID

如果要使用相同的文件夹设置和设置从全新的UI状态开始，只需复制.code-workspace文件。

因此，“将工作空间另存为”操作将不得不询问用户副本是否应具有不同的ID。

由于用户不知道该ID是什么，所以这很棘手。拥有两个选项“使用当前状态克隆工作区”和“新建空白工作区”可能更直接。但这是UX，您必须对此进行分析。

fgallardograzio 于 2017-09-19

同意Franc，将所有项目配置文件保留在设置中
在项目中的文件夹中，查看具有正确权限的Eclipse IDE
方法。它具有项目和工作区设置的概念，
项目覆盖工作空间中的默认设置。工作区只是一个文件夹
代表项目的文件夹。所以在工作区中有.vscode文件夹
文件夹，每个项目都有它自己的.vscode文件夹。而且请不要
刚刚投票提及Eclipse IDE。

在2017年9月18日星期一8:52 PM，Franco Gallardo Grazio <
[email protected]>写道：

@bpasero https://github.com/bpasero恕我直言，UI状态的处理方式
（如果使用的是.code-workspace文件中的ID字符串，或者使用
文件路径作为ID）是不够的。
重命名.code-workspace文件或其任何父文件夹，或移动
在我看来，失去UI状态是完全不直观的。一世
认为不知道其幕后工作原理的人绝对有
没有任何线索说明他们失去了先前的UI状态的原因以及如何获取
回来了。
不应将其绑定到文件中文件的绝对路径
系统！
这适用于UI状态与当前位于
稳定释放。一开始我对此很困惑，直到我
做了一些谷歌搜索。
IMO如果仅处理一个文件夹，则应保存UI状态
在.vscode文件夹中。如果我们要处理的是多根工作区，
UI状态应另存为单独的文件，与
.code-workspace文件使用适当的命名约定（或者也许
在该文件本身中，尽管混合设置和状态可能不是
好主意）。
如果正确实施，则将允许用户完全访问
到UI状态，将新的UI状态附加到给定的工作空间（多根或
否）等
我希望能够在不同计算机之间同步UI状态，例如
在办公室工作，然后回家，拿起笔记本电脑或其他物品，
继续我离开的地方。
将几个UI状态附加到工作区，并可以轻松地在之间切换
它们（菜单/键盘绑定/命令/等）在使用不同功能时会
也很棒。 .vscode中可能存在不同的.code-uistate文件
自动列出，或根据
主.code-workspace，或列在数组中。
我正在考虑将其作为项目和工作空间的扩展
在Sublime Text上工作。功能相同，设计不同。在这种情况下
VS Code工作区将类似于Sublime项目，但不同
VS Code UI状态将类似于Sublime工作区。
关于此问题：
奇怪的是，您只需输入以下内容即可编辑文件中的ID
另一个价值
是的，完全是。从那里删除ID是正确的选择。
共享工作空间文件时，如何处理id尚不清楚
与其他人（应该更改ID？ID应该是uuid吗？）
好吧，如果我们有myproject.code-workspace和myproject.code-uistate
然后由用户决定是否共享其UI状态。
无需再思考该ID的含义，其生成方式（如果需要）
一个UUID，以避免共享时发生冲突等
是否要共享文件夹设置和设置？发送myproject.code-workspace，
不用担心。
想分享一切吗？发送两个文件。
无法复制工作空间文件并单独打开它
窗口，您必须先在复制的文件中更改ID
如果要使用相同的文件夹设置从全新的UI状态开始，
设置只是复制您的.code-workspace文件。
因此，“将工作空间另存为”操作将不得不询问
用户，如果副本应具有不同的ID
由于用户不知道该ID是什么，所以这很棘手。也许会
有两个选择“使用当前克隆工作区
状态”和“新的空白工作区”。但这是UX，您必须做一个
分析。
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/Microsoft/vscode/issues/396#issuecomment-330396242 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAQsBQ5rdj3VGoNwy77jfSQ7V_tqWFOfks5sjxBYgaJpZM4Gm3nX
。

-
丹尼尔·索科洛夫斯基
技术架构师

稳定技术集团有限公司
电话：+1（613）634-7410
http://www.stantive.com

保密通知：
传输的信息仅用于个人或实体
可以解决，并且可能包含机密和/或特权
材料。任何审查转播或其他用途
由人员根据此信息采取任何行动，或
禁止除目标收件人以外的实体。如果收到
这是错误的，请立即通过电子返回与发件人联系
传输，然后立即删除此传输，包括所有
附件，不得复制，分发或公开。

danielsokolowski 于 2017-09-19

@danielsokolowski我了解项目覆盖设置工作区的概念。在vscode中，您具有常规设置，用户设置（覆盖常规）和工作区设置（覆盖用户或常规）。每个项目已经有机会拥有自己的.vscode文件夹（其中包含工作区设置）。您是否在建议其他文件夹，该文件夹将嵌套项目以共享设置信息？在Visual Studio术语中，这似乎类似于“解决方案”文件/文件夹。

@fgallardograzio将项目配置与同一文件中的设置混合在一起将强制进行耦合。 ui的功能听起来更好，因为它是与此发行凭单分开的另一个功能。既然Insiders构建文件中多余的根有了一些不错的布局，也许扩展可以填补ui部分的空白。谢谢。美好的一天。

pr-yemibedu 于 2017-09-19

@Yemi ，是的，所以Elcipse允许我打开不同的工作区
只是包含表示项目的各个子文件夹的文件夹。一世
个人使用两个工作区，一个用于开发Eclipse IDE，另一个用于
我所有与工作相关的项目。主要收获是设置只是
可读文件存储在各自的设置文件夹中-http: //wiki.eclipse.org/IRC_FAQ#Where_are_Eclipse_preferences_stored.3F-
这对我来说很合逻辑。

在任何情况下，对于任何IDE都值得一提的注释/提示
独立项目，例如说您希望的workspace/your-awesome-library
包括在另一个项目中
workspace/my-wiget/libraries/your-awesome-library一个可以使用结点
或根据操作系统进行硬链接-我发现此清洁器比git / hg subrepos更干净
概念。

2017年9月19日星期二上午10：33，Yemi Bedu @ P＆R [email protected]
写道：

@danielsokolowski https://github.com/danielsokolowski我了解
项目的概念会覆盖设置的工作区。在vscode中
具有常规设置，用户设置（覆盖常规）和工作区
设置（覆盖用户或一般用户）。每个项目已经有
有机会拥有自己的.vscode文件夹（其中包含工作区设置）。
您是否正在建议一个其他文件夹将项目嵌套到
共享设置信息？这似乎类似于“解决方案”
用Visual Studio术语的文件/文件夹。
@fgallardograzio https://github.com/fgallardograzio有一个项目
配置与同一文件中的设置混合将强制
耦合。 ui的功能听起来更好，因为另一个功能与
这张票。现在，Insiders构建具有一些不错的布局
文件中的多余根，也许扩展可以填补ui的空白
部分。谢谢。美好的一天。
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/Microsoft/vscode/issues/396#issuecomment-330558669 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAQsBajECULDuQiqUZj6SRdfwJG-Bcw0ks5sj9CfgaJpZM4Gm3nX
。

-
丹尼尔·索科洛夫斯基
技术架构师

稳定技术集团有限公司
电话：+1（613）634-7410
http://www.stantive.com

保密通知：
传输的信息仅用于个人或实体
可以解决，并且可能包含机密和/或特权
材料。任何审查转播或其他用途
由人员根据此信息采取任何行动，或
禁止除目标收件人以外的实体。如果收到
这是错误的，请立即通过电子返回与发件人联系
传输，然后立即删除此传输，包括所有
附件，不得复制，分发或公开。

danielsokolowski 于 2017-09-20

仍然没有添加此功能吗？

这对我来说很重要。我正在一个项目，该项目由2个独立的存储库组成：Web前端和api。如果可以在一个“项目”中打开这两个文件夹，那将是很好的。

当然，我可以通过将2个存储库克隆到一个文件夹中并打开该文件夹来解决此问题，但这不适用于每种情况。特别是如果您有多个项目依赖于单个存储库（即，共享相同的API）。

此功能对于将代码用作文档的人员也将很有用。

JamesTheHacker 于 2017-09-24

👍5

@JamesTheHacker有时会使用vscode-

Jeyanthinath 于 2017-09-25

👍2

发行时，VSCode版本可能会升至2.0。只是说:)

borekb 于 2017-09-25

👍5 😄4 👎1

有关此功能的快速问题：

此功能支持将具有存储库的多个文件夹添加到现有工作空间。它还支持单存储库配置吗，我想在一个单存储库中打开多个项目，但是由于它们在一个存储库中，因此它们没有自己的git存储库。因此，从项目的角度来看，它们没有.git文件夹-其中一个祖先文件夹具有它们。

您可能会问为什么不将mono-repo文件夹作为一个大文件夹打开并直接在其中工作？有两个答案：

（对我而言不那么有趣）mono-repo中有太多项目，而我仅对其中一些感兴趣。
许多插件都假定一个项目仅包含一个...项目。例如，只有一个npm软件包。因此，他们在项目的_root_中查找内容。示例：VSCode的npm插件，vscode的mocha插件以及VSCode本身的许多功能-例如，我无法在launch.json中指定相对于当前文件，即“ node_modules文件夹，它是当前文件的最接近的祖先”。

经过上下文解释后，我的问题很简单-此功能是否支持那些.git文件夹是其根源的项目？如果是这样，则有可能在单仓库中使用此功能。

giltayar 于 2017-09-26

@borekb是的。我不知道Microsoft的人员如何管理其版本，但我认为这对于一个主要版本来说已经足够了

Guema 于 2017-09-26

经过上下文说明后，我的问题很简单-此功能是否支持项目.git文件夹是其根的祖先？如果是这样，则有可能在单仓库中使用此功能。

如果您只是打开git repo的子文件夹，那么已经有很长时间了。

joaomoreno 于 2017-09-26

👍1

+1

Sublime和Atom应该做到这一点。没有更好的理由。这是新的MS，伙计们，我对您完全有信心。 :)

inestyne 于 2017-09-26

👎24 😕2

你好，
@inestyne，如果您请阅读@Jeyanthinath等以前的文章，您将意识到已经使用VSCode Insiders评估了此功能。甚至还有要检查的路线图。因此，请使用该产品并在其迁移到稳定版本之前提供反馈，以便我们都能获得最好的产品。谢谢。美好的一天。

pr-yemibedu 于 2017-09-27

👍11

只需阅读线程并使用Insiders OMG。我要退订...您不读的巨魔是不可能的。谢谢@ pr-yemibedu

nahuelhds 于 2017-09-27

👎6 👍2 😄1

敏感

inestyne 于 2017-09-27

👎14 😕3 😄3

由于该线程长达2年，并且该功能现在似乎已在Insiders的内部，因此是否有办法标记此线程，这样比从顶部读取整个线程更明显？

bitblitz 于 2017-10-06

👍19 😕1

缺少的一件事是能够通过CLI使用新的工作区打开新窗口。

jearle 于 2017-10-20

@jearle应该像以前一样使用code-insiders <folder>创建一个新窗口/工作区，不是吗？
code-insiders -a <folder>将该文件夹添加到当前窗口。

Tyriar 于 2017-10-21

@Jeyanthinath谢谢！和@JamesTheHacker做着同样的事情，它将对我有帮助！

jhonnymoreira 于 2017-10-21

@Tyriar要获得我想要的功能，我必须执行以下命令：

code .; code -a .

code .将文件夹作为非工作空间打开，然后code -a .将其自身附加到先前打开的窗口作为工作空间，使我可以多次打开同一文件夹。

jearle 于 2017-10-23

我个人认为这也需要更改。我正在两个不同的git repos中使用ionic和自定义服务器，这不是很容易。至少可以打开两个单独的“项目选项卡”的功能还是很棒的。

我之所以选择Atom，是因为它的越野车和速度缓慢。

dark-swordsman 于 2017-10-27

@ dark-swordsman您可以在Mac上启用nativeTabs

felixfbecker 于 2017-10-27

@felixfbecker在Windows上可能吗？

编辑：我完全搜索了设置文件，没有选项。这就是为什么我问。

Edit2：此外，关于如何启用vs insiders尚无明确的资源

dark-swordsman 于 2017-10-30

你好，
@ dark-swordsman您未启用VS Insiders。它是VSCode的内部版本，具有一些尚未最终确定稳定的额外功能，并以某种方式为您提供了额外的编辑器命名空间以供使用（您可以并排安装它们而不会发生设置或扩展名冲突）。谢谢。美好的一天。

pr-yemibedu 于 2017-10-30

在稳定版本中，默认情况下现已启用对多根工作空间的支持。

panel-red2

请参考我们的文档以获取其所有功能的完整说明。扩展作者应参考我们的Wiki ，该

请在遇到多根问题时毫不犹豫地提出问题，我们仍在计划进行调整，并为将来的扩展提供更多API，以与多根工作区一起使用。

bpasero 于 2017-11-02

🎉38 👍29 ❤13 😄5 😕1

很好，但是什么时候可用？您说它在稳定版本中，但是我有最新的稳定版本（1.17.2），无法更新。另外，在您刚刚引用的文档中，它表示该文件仍在Insider的内部，并将很快在稳定版本中发布。

~~我知道发布下一个版本可能要过一会儿，但我看到此通知希望它可用。~~

编辑：对于我的不耐烦，我深表歉意。我只是尝试以手动方式打开一个新窗口（再次调用.exe），它没有用，但是没有在“文件”>“打开新窗口”中查找。现在可以使用。期待发布下一个版本。 👍

dark-swordsman 于 2017-11-02

👍4

@bpasero请关闭此＃35849未解决的问题，因为此＃396功能已完成了预期的功能。

karuppasamy 于 2017-11-10

👍1

只是一个简单的问题。当我打开更多文件夹时，是否可以切换要编译的文件夹？目前，它始终是稳定版本中的第一个。

编辑：这可能是针对PlatformIO扩展的创建者，但我都要求双方。以防万一...

DJManas 于 2017-11-11

@DJManas听起来这取决于您要使用的扩展名，因此您应该询问扩展名的作者。

bpasero 于 2017-11-13

@bpasero好的，我同时做了，谢谢您的答复。

DJManas 于 2017-11-13

Vscode: 添加对在同一窗口中打开多个项目文件夹的支持

最有用的评论

所有380条评论

：sparkles：更新：sparkles：

为什么要花这么长时间？

迄今为止的评论摘要

当前解决方法

什么时候发表评论？

相关问题