vscode 🚀 - 正确的标签用于打开文件

+1

通过自定义扩展名可以添加标签吗？我迅速查看了文档，但似乎无法在当前的API中添加该类型的功能

inakianduaga 于 2015-11-20

通过自定义扩展名可以添加标签吗？

不，目前无法通过扩展程序进行操作（另请参见http://code.visualstudio.com/docs/extensions/our-approach）

bpasero 于 2015-11-20

👎33 👍4

+1

vasumahesh1 于 2015-11-29

：+1：

snehilmodani 于 2015-12-18

：+1：

Xety 于 2015-12-21

+1

即使在Visual Studio中，选项卡也是默认的工作方式，更不用说其他文本编辑器，例如sublime。

Nicte 于 2015-12-21

👍7

对于那些缺少选项卡的选项，您是否尝试过使用Ctrl+Tab浏览打开文件的历史记录？

bpasero 于 2015-12-21

👎31 👍12 ❤2

是。但是，即使关闭文件，文件仍保留在Ctrl+tab上下文中。体验与Sublime / Atom的体验不同。

snehilmodani 于 2015-12-21

👍13

@snehilmodani对，如果列表仅显示资源管理器的“工作文件”部分中的内容，这会有所帮助吗？您至少可以使用工作文件列表吗？

bpasero 于 2015-12-21

👍1

那很好啊！

附带说明：使用文件名作为选项卡的布局不是更加用户友好。它可以扩展为具有一个或多个选项卡部分，每个部分都具有自己的一组打开的文件。（同样我在这里以崇高文字为参考）

snehilmodani 于 2015-12-21

我认为是否具有选项卡与具有部分无关。今天，您可以在VS Code中并排打开最多3个编辑器，因此我们有许多部分。由于没有选项卡，因此我们不会在这些部分中添加多个文件，并且您也不能有空白部分（这是单独的UX讨论）。

回到Ctrl + Tab：从一开始我们就一直在团队工作，而没有选项卡，实际上我们很长时间甚至没有工作文件视图，实际上，团队中没有多少人在使用它。我们发现，对于我们来说，打开或关闭哪个文件都没关系。我们的想法是考虑上次编辑哪个文件的时间顺序。因此，当我调出Ctrl + Tab时，通常会向我显示我上次所在的文件。我不是真的在看那里的文件数量，我只对最大的前5个文件感兴趣。该模型的优点是您根本不必管理布局和选项卡。在文件之间导航时，自然会进行管理。

我们可以为工作文件添加一个文件选择器，但是如果人们可以说服人们像今天这样使用Ctrl + Tab并了解问题所在，那将很有趣。

bpasero 于 2015-12-21

👍8 👎7

@bpasero我会给ctrl+tab一枪，我只是意识到它可以用于转到上一个文件，这是我想要的并且直到现在都没有研究过。很好。

顺便说一句，不管是否有人可以习惯使用ctrl+tab作为制表符的替代方法，新的VS代码用户可能会因为缺少制表符而推迟，所以如果仅出于市场份额的原因，我会建议使用选项卡选项。其他所有编辑器都使用制表符（无论好坏），并且不使用制表符会给VS代码带来不必要的输入障碍。我使用VS代码而不管制表符支持是什么，因为它提供了出色的打字稿支持，但是如果不是那样的话，我不知道我是否会在最初的几次尝试中坚持使用它。

inakianduaga 于 2015-12-21

是的， Ctrl+Tab就是要追溯到正在处理的文件的历史记录。您可以按住Ctrl键，然后重复按Tab次以返回1个文件以上。

bpasero 于 2015-12-21

👍1

Ctrl+tab是一件很棒的事情，我完全喜欢它。甚至Atom都错过了它。

关于每个部分中的选项卡和多个文件：即使在Sublime Text中，我们也可以并排打开3个编辑器，但它们仍提供部分选项卡式布局。我同意您所说的混乱，管理编辑器的布局是一项艰巨的任务，但是人们还是习惯了。
我很想成为社会实验的一部分，在这个实验中，您试图说服我们摆脱与编辑人员之间混乱的基于布局的交互。

snehilmodani 于 2015-12-21

我同意您所说的混乱，管理编辑器的布局是一项艰巨的任务，但是人们还是习惯了。

好吧，我敢肯定，我们可以找到更多的UX示例，这些示例曾经使我们习惯于某些东西，然后又习惯了一些更好的东西:)。考虑一下手机键盘与智能手机的触摸交互。

我很想成为社会实验的一部分，在这个实验中，您试图说服我们摆脱与编辑人员之间混乱的基于布局的交互。

是的，我认为我们需要在2016年做类似的事情。 @stevencl fyi

bpasero 于 2015-12-21

👎4

关于每个部分中的选项卡和多个文件：即使在Sublime Text中，我们也可以并排打开3个编辑器，但它们仍提供部分选项卡式布局。

我同意允许使用更稳定的部分的选项，以便我们可以有空的部分，但是能够看到此部分中的选项卡只是其中文件的直观表示，在大多数情况下，它们会增长得太多，以至于您最终没有看到什么。我认为，除非您主动管理并关闭它们，否则选项卡不是显示打开文件列表的好方法。

bpasero 于 2015-12-21

👍2

我认为，除非您主动管理并关闭它们，否则选项卡不是显示打开文件列表的好方法。

有些人实际管理它们，而其他人则在右侧关闭标签。

snehilmodani 于 2015-12-21

非常感谢您的反馈。

我们在UX待办事项（＃1133）上存在一个问题，以改善工作空间管理（管理打开的文件，历史记录等），这是一个问题。我们的目的是改善用户体验，使管理打开的文件和最新文件的列表变得简单明了，并使用户可以专注于自己的代码，而不必对VS Code UI给予过多的关注。

我们的假设是当前系统具有一些粗糙的边缘（例如，关闭编辑器实际上会关闭编辑器，但是我们认为也许应该显示先前在该编辑器中打开过的文件），并且平滑这些粗糙的边缘会帮助创造更好的体验。

我们会定期对产品进行用户体验研究。实际上，这就是我们在产品中设计大量UX的方式。我们会根据实际反馈对设计进行迭代，以确保我们充分了解人们对产品的看法和想法，以告知我们的设计。

如果您将来想参加这些研究（最早直到一月中旬我们将不再运行），请告诉我，我会将您的名字添加到列表中。

stevencl 于 2015-12-21

如果您将来想参加这些研究（最早直到一月中旬我们将不再运行），请告诉我，我会将您的名字添加到列表中。

注册我！

snehilmodani 于 2015-12-22

我认为，除非您主动管理并关闭它们，否则选项卡不是显示打开文件列表的好方法。

标签管理是我发展的无意识和不羁的一部分。 VS-proper的离散选项卡较小，不易干扰（vscode已经使用文件名占用了该选项卡所在的空间）。我确实同意失控的标签垃圾邮件是一个问题，创新并解决这个问题可能会很好，但是我要说的是，优先级比完全拥有标签低。 VSCode需要达到最低工作状态。现在，我发现它已经非常接近了，但是我还不能高效地工作。从既定模式开始可能会使我们更快地工作。

值得记住的是，并不是每个人都是Web开发人员，我发现对于不同的语言和应用程序样式，工作流程往往会略有不同。作为本地开发人员，通常有一组可见的关联文件； cpp + h ，也许也是inl ，并且您通常不会单独处理一个文件。我经常在代码旁边看到一个反汇编视图。我的编辑器环境跨越2个监视器，在任何给定时间都可以看到4个文件，而我将很难在比此更严格的环境中工作。
我还想念能够抓住一个选项卡并将其撕成一个小的浮动窗口，我经常将其设置为“始终位于顶部”，该窗口通常用作参考点，或者我正在做很多复制/往/从。

例如，现在，我正在尝试重构和简化一些遗留代码。我当前的文件工作集是... component.cpp，component.h，component.inl，componentimpl.cpp，componentimpl.h，icomponent.h。那是6个文件！而且我无法摆脱偶尔对外围其他文件进行的调整。当我处理那种样式的项目时（在2个文件之间翻转），我自由地使用ctrl-tab，但是在此上下文/代码库中，我简直不能没有选项卡。

重构和维护遗留代码与编写新代码（我想你们正在做，并且主要用作UX设计指南）的工作流程完全不同。

我的意思是；现代的愿望是重塑一切，近年来，我们在UX设计上取得了长足的进步。 vscode已经提供了其中的一些功能，但是在决定改变人们数十年来的工作方式时，请小心谨慎并运用良好的判断力。建立许多既定的设计是因为它们高效且有效，而不是因为它们过时并且需要更新才能变得更加时尚:)

我很高兴有机会参与这些重点研究！

TurkeyMan 于 2015-12-23

👍16

我的意思是；现代的愿望是重塑一切，近年来，我们在UX设计上取得了长足的进步。 vscode已经提供了其中的一些功能，但是在决定改变人们数十年来的工作方式时，请小心谨慎并运用良好的判断力。

对我来说就是这样。其实我不能没有标签工作。多年来，我一直在使用Tabs系统，而没有它们，我真的迷失了。这是我实际上不使用Code的原因之一。

建立许多既定的设计是因为它们高效且有效，而不是因为它们过时并且需要更新才能变得更加时尚:)

：+1：

Xety 于 2015-12-23

👍3

到目前为止，与在某处仅列出“工作文件”相比，我还没有听说过使用制表符的充分理由。能够获取文件并将其拖到新窗口中显然不是选项卡系统的好处，它是没有选项卡就可以拥有的功能。

人们是否真的想打开选项卡中的文件，四处移动并最终关闭它们？这是因为您已经习惯于此，还是这样做确实有价值？该值是否能够设置一个活动的工作文件集，您稍后将其关闭以启动新的文件？我不知道拥有选项卡有什么好处，以至于无法用其他表示方式实现。我不接受所有人都习惯使用制表符的论点:)。很多人习惯于保存文件，但仍然有具有自动保存功能的编辑器，人们似乎很喜欢它。

bpasero 于 2015-12-23

👍10 👎9 😕3

即使不是默认情况下，让用户选择通过某些选项激活选项卡功能对我来说几乎一样。

例如，如何让用户将“工作文件”部分移动/拖动到顶部（可以说将它们转换为选项卡）。再次，用户可以选择他想如何工作，我认为那太好了！

Nicte 于 2015-12-23

👍4

对我而言，标签的外观与其说是我错过的行为，不如说是标签的外观。（例如，您可以使Sublime Text看起来像VS Code，因为您可以隐藏选项卡栏，而是在侧栏中显示打开的文件...但是它们的行为仍然与选项卡完全一样。）

我对VS Code所做的第一件事是交换它的关闭文件并关闭活动的编辑器键盘快捷键，以便当我按ctrl + W时实际上会关闭文件，而不是将其留在工作文件中并弄乱ctrl + tab。

但是即使如此，每次关闭文件时，我都会遇到一个空白屏幕，必须按ctrl + tab才能显示最新的仍打开的工作文件（哎呀，当它是最后一个文件时，我似乎还需要在ctrl + tab之后按Enter；不确定是什么意思。在任何其他编辑器中，关闭当前文件时，我都会立即被最新的或相邻的打开文件（选项卡）打招呼。

此外，工作文件之间的ctrl + tab似乎以最新的顺序工作，而不是通常按其出现或排列的顺序工作的选项卡。（我已经看到一些编辑器同时支持两者。）

我不使用分割窗口，因此，如果这些行为差异中有任何与之相关的东西，那对我来说就是迷失了。如果从那个角度理解它，也许我会更好地理解它，但是不拆分仍然是最常见的用例吗？

无论如何，这种小但频繁的摩擦使我远离VS Code并回到其他编辑器。是的，您可以说VS Code的运作方式与我惯常的有所不同。但是，当我习惯_works_的方式以及VS Code的不同操作方式引起的摩擦时，我会尽快使用其他编辑器来避免处理该摩擦，这是很大的事情。

kfranqueiro 于 2015-12-23

👍4

是的，我可以看到一个模型，其中编辑器区域的行为类似于选项卡，而没有显示选项卡。我们想在明年进行探索。

顺便说一句，有一个扩展名-一旦您关闭编辑器，就从工作文件中打开下一个扩展名。如果结合@kfranqueiro的建议将其与更改键绑定结合使用，您将获得非常接近的恕我直言。

bpasero 于 2015-12-23

这是链接： https :

bpasero 于 2015-12-23

到目前为止，与在某处仅列出“工作文件”相比，我还没有听说过使用制表符的充分理由。能够获取文件并将其拖到新窗口中显然不是选项卡系统的好处，它是没有选项卡就可以拥有的功能。

当然，也许可以用其他方式来做...但是为什么呢？除非您提供一些重大改进或创新。

人们是否真的想打开选项卡中的文件，四处移动并最终关闭它们？

是

这是因为您已经习惯于此，还是这样做确实有价值？

一方面是习惯，另一方面是因为没有人提出任何明显优越的东西。如果要坚持人们与自己几十年的习惯作斗争并对其进行再训练，创新应该会带来巨大的优势。

该值是否能够设置一个活动的工作文件集，您稍后将其关闭以启动新的文件？

我不确定我是否完全理解这句话。您是否正在尝试描述使用多个“工作文件”集的替代方法？很难想象。我不确定这是否会普遍有用。对于遗留，维护和重构任务，我认为以这种方式工作将是一个严重的劣势，因为通常不预先知道您的工作集，而是随着工作而出现的。传统模型在这些工作流程中已经可以正常工作。

我不知道拥有选项卡有什么好处，以至于无法用其他表示方式实现。

从不同的角度来看；考虑利用空间。在代码窗口的顶部已经有一个选项卡，它是文件名所在的位置，它的名称周围没有选项卡矩形（它的行为就像是一个选项卡；如果您单击鼠标中键，它将关闭！）。在代码窗口上方文件名的右侧，当前是空白的浪费空间（应在其中放置标签）。
工作区的左上方是“工作文件”列表。这是双重浪费的空间，因为它根本不需要存在，它的空间可以移到标签通常所在的间隙，以填充该浪费的空间。

除了空间利用和习惯倾向，我还发现了更多的实际差异。我喜欢将选项卡与绑定到的编辑器窗口相关联。我通常至少打开2、3，通常4个代码窗口（以vs-proper表示），每个窗口都有几个相关的标签。也许在一个窗口中我有widget.cpp/.h ，在另一个窗口中我有gizmo.cpp/.h/.inl 。这些选项卡在逻辑上与它们附加到的代码窗口相关联，我觉得很令人满意。

我不接受所有人都习惯使用制表符的论点:)。很多人习惯于保存文件，但仍然有具有自动保存功能的编辑器，人们似乎很喜欢它。

好吧，不管接受与否，人们发现它是一个合理而有力的论据。但是，如果您有更好的想法，我会保留我的判断力。无论如何，如果您认为可以在选项卡上进行有意义的改进，可以尝试一下，但不要仅凭“时髦”创新就顽固地通过它；）..要想摆脱现状，它必须具有更好的优势。。

我只能说，当前的“工作文件”列表绝对不是最好的。它基本上是选项卡，只是垂直排列，但缺点是选项卡与绑定的编辑器窗口分离，并且列表位于浪费的空间中，而选项卡的通常位置为空。
我也不喜欢“工作文件”列表具有动态高度，这意味着项目树垂直移动，并且我怀疑如果“工作文件”具有固定的高度和垂直滚动条，我会更不喜欢它代替。

它只是不优于常规标签，因此没有令人信服的理由去适应……我认为:)

TurkeyMan 于 2015-12-24

👍18 ❤5 🎉1

+1 @土耳其人

Nicte 于 2015-12-24

👍1

在VS Code团队中，自开始（4年）以来，我们一直在没有选项卡和文件的情况下工作，并且我们没有丢失任何东西。因此，我个人同意工作文件部分是浪费空间，并且我将该部分保持折叠状态。但是，我们还启用了自动保存功能，通常不关心脏文件。引入工作文件主要是为了为脏文件和无标题文件提供显示的位置。后来我们决定，它也是一个有用的地方，可以帮助缺少传统标签的人们，因为它是一种相似的表示形式，只是以另一种UI方式。

我们确实在编辑器上方保留了空间以显示文件信息和操作。有人可能会争辩说，此空间与制表符所需的空间相同。但是我反对制表符的观点是，通常水平空间不足以显示工作文件列表，因为您很快就会得出以下结论：

screen shot 2015-12-24 at 09 28 30

这是我们试图避免的噩梦：您需要在选项卡列表中左右滚动，以找到所需的文件。只要您没有打开的标签数多于水平显示的标签数，选项卡就只能正常工作。一旦选项卡变得足够小以至于文件名被隐藏，您就需要开始关闭其他选项卡以查看发生了什么。

现在，显然在其他方面，工作文件也存在类似的问题。这就是为什么我们团队中的人员通常只使用Ctrl+Tab来处理所有事情，而不关心是否打开了什么。

总结：工作文件不是替换标签的答案，而是工作文件和Ctrl+Tab 。而且我们的团队或多或少100％仅使用Ctrl+Tab而已。

bpasero 于 2015-12-24

👎21 👍17 ❤1

您的图像似乎不必要地夸大了问题；不切实际的狭窄窗口，对角线的标签边缘，标签中的文本过多，右侧的点;）
vs-proper可以很好地钉住这些标签，并且没有理由不像它那样小心翼翼地滚动小标签。

适用时，我是一个非常自由的Ctrl-Tab用户，但是除非您正在积极地编辑不超过2个或3个文件，否则您不能使用Ctrl-Tab。
我怀疑您在此问题上的观点可能会偏向于您的特定项目，并且可能包括语言偏见。在C / C ++中，当您接受.h ，典型的工作文件数量将增加一倍或两倍，而在我的情况下，通常是.inl补充每个.cpp 。 Ctrl-Tab在这种情况下效果不佳，并且您倾向于结合使用Tab-管理使用Ctrl-〜（切换cpp / h；我也发布了功能要求）。
或考虑使用Java，每个类（无论大小如何）都需要存在于其自己的文件中。

在我当前的日常工作中，我经常会有一组10个文件的工作集，按这种方式工作时Ctrl-Tab对我没有用。最实用的工作流程是2-4个编辑器窗口，每个窗口有两个选项卡。我之所以没有选择此布局，是因为我喜欢它。它只是出现了，因为它是此特定工作最有效的工作区布局。

TurkeyMan 于 2015-12-24

👍17 ❤1 👎1

+1
通常，我需要拆分编辑器，并且关闭选项卡比拥有10个以上的工作文件更直观。

我通常也只处理文件的子集，并且希望保留这些文件。对于我个人而言，5/10比列出10列表更容易管理。我也在积极地在他们之间不断前进。选项卡还可以帮助您直观地表明您的打开空间过多-@bpasero显示的“选项卡地狱”。

我确实接受选项卡并不一定是窗口管理的圣杯。但是，对于要处理多组文件的语言或项目，使用选项卡进行管理的工作量较小。

一个简单的示例是带有标签的.cpp和'.h'，两次单击都聚焦在窗口顶部，而使用工作文件则需要进行3-4次点击，需要您选择编辑器，然后选择要编辑的新文件。

标签和自定义标签还可以使添加一些有趣的扩展变得更加容易。一个示例是控制台或绘图选项卡。这些要么需要在文件选择器部分中的特殊条目，要么必须在当前系统关闭时被丢弃。我经常回到地块，因此关闭窗口将需要重新绘制。否则将关闭控制台，并且其中的数据丢失。

但是，如果有合适的替代方法，那么我很乐意对其进行测试。我只是觉得当前屏幕上的水平空间大于当前窗口管理设计没有利用的垂直空间。虽然我不喜欢标签在垂直方向上大于每个窗口中当前名称的情况。

mikewl 于 2016-01-03

我很好奇为什么在实现选项卡方面会有如此之多的推迟。从技术上讲，这并不困难，并且已经实现了工作文件。为什么不同时让用户决定？

这听起来几乎像是空格v。Tabs，2.0

ianwesterfield 于 2016-01-28

👍15 😄12

我很好奇为什么在实现选项卡方面会有如此之多的推迟。从技术上讲，这并不困难，并且已经实现了工作文件。为什么不同时让用户决定？
这听起来几乎像是空格v。Tabs，2.0

完全同意，将功能作为一个选项进行推送（如果它使反制表人员感到高兴，则默认为关闭），并通过统计信息/反馈来跟踪使用情况，而不是无休止地探讨其是否有意义，可能会更容易。

inakianduaga 于 2016-01-29

👍3

我意识到，似乎我们一直在对此进行无休止的理论研究，而不是实际为此做些什么并为此道歉。但是，我们确实有一个项目可以在我们的积压订单中解决此问题（以上参考＃1133）。由于我们一直在努力进行本地化和可访问性，因此我们最近才花大量时间。

如前所述，我们已经意识到当前文件管理经验中存在的问题，我们需要进行一些更改以改善体验。

VS Code的目标之一是，当我们对UI和UX进行更改时，我们确保VS Code保持轻巧，功能强大的编辑器，使用户可以专注于自己的代码。我们尝试实现这一目标的方法之一是非常小心我们添加到产品中的任何新UI。

我们对添加选项卡的关注是它引入了另一组问题，最终导致用户需要专注于UI而不是代码。例如，我们在Visual Studio上的经验向我们表明，许多用户经常会打开许多选项卡，其中包含不再需要的文件，并且最终会使工作区混乱。当用户正在寻找文件和其他代码资产时，这会导致一些问题。为了解决这些问题，需要更多的UI，允许人们关闭所有选项卡，关闭除该选项卡之外的所有选项卡，选项卡溢出控件等。我们希望避免这种情况，并希望我们正在从事的设计能够帮助我们实现这一目标。

这不是意识形态的辩论-我们确实是在努力维持我们认为提供轻量级，强大的体验的最小美学。我们只是非常谨慎地在产品中引入新的UI和UX。

经过几轮的设计和研究，我们最终有可能引入标签。但是，只有在了解到这是改善用户管理其使用的文件和资产的方式的最佳方法之后，我们才会这样做，但最终不会使UI混乱。

我希望这有助于解释我们对此的看法。我再次表示歉意，因为它使我们看起来像是在注视着肚脐，对此并未采取任何措施。

stevencl 于 2016-01-29

👍10 👎3

谢谢@stevencl ，这很不错，至少它在雷达上，并且正在进行一些集思广益。

我们对添加选项卡的关注是它引入了另一组问题，最终导致用户需要专注于UI而不是代码。

我觉得我现在需要专注于UI而不是代码，因此该参数可以双向使用。 :)

许多用户通常最终会打开许多选项卡，其中包含不再需要的文件

您这么说很有趣，因为我感觉工作文件的一部分是_was_，以鼓励同时打开更多文件。您在此处描述的内容也容易在工作文件中发生，至少在默认的键绑定中也是这样（这就是为什么我在切换键绑定以关闭活动编辑器并完全关闭工作文件时也是如此）。

归根结底，如果VS设法有选择地复制选项卡的_behavior_（似乎至少与＃1133中的一件事情有关），同时仍然将其放在一边，那可能是一个很好的开始。 Ctrl + tab顺序为MRU与外观顺序是另一回事（Sublime允许通过不同的可绑定命令两者）。

kfranqueiro 于 2016-01-29

@stevencl ，感谢您的回复。我想评论您的一些观点：

[...]我们知道当前管理文件的经验所带来的问题，并且我们需要进行一些更改以改善体验。

我当然很期待VS Code的美好前景。当我听到微软将功能强大的IDE（如Visual Studio）带入Windows之外的世界，并为Electron拥抱应用程序开发的新范例而感到激动时，我感到非常兴奋。恭喜您的工作！

VS Code的目标之一是，当我们对UI和UX进行更改时，我们确保VS Code保持轻巧，功能强大的编辑器，使用户可以专注于自己的代码。

我认为没有人能为制表符带来令人信服的论点，这些选项卡会使界面变得虚弱，呆滞或分散注意力。实际上，选项卡的水平空间比项目树视图上方的垂直空间大得多。对我来说，将工作文件存放在这里会使窗口的左侧看起来比必须的更加混乱。

我们对添加选项卡的关注是它引入了另一组问题，最终导致用户需要专注于UI而不是代码。

如果所有内容都集中在代码上，那么是否有理由使用TextEdit或Notepad以外的任何东西？在大多数编辑器中，出于所有意图和目的对功能进行规定都是相同的，用于实现该功能的UI / X及其质量实际上是产品与众不同的地方。

例如，我们在Visual Studio上的经验向我们表明，许多用户经常会打开许多选项卡，其中包含不再需要的文件，并且最终会使工作区混乱。当用户正在寻找文件和其他代码资产时，这会导致一些问题。

我认为对于选项卡或工作文件列表而言，这无关紧要。当使用多个文件时，您将总是不得不集中精力查找代码资产。

即使这样，工作文件列表仍然不能解决问题。工作文件过多会导致列表滚动，并且列表无法扩展。因此，代替最终滚动选项卡，您可以更快地向下滚动工作文件列表。

我们确实在努力保持我们认为提供轻便，强大的体验的最小美学。我们只是非常谨慎地在产品中引入新的UI和UX。

我可以在某种程度上赞赏并支持这一立场。当社区发出声音时，您必须开始谈论用户采用率。这不是为什么您将VS Code缺乏可折叠性作为3月路线图中的用户采用问题吗？有些事情就是它们的样子，这是有充分理由的。我想到了Windows上的开始菜单和OSX上的扩展坞。

[...]我再次道歉，因为它使我们看起来像是在注视着肚脐，对此并未采取任何措施。

那绝对不是我的主意，所以不用担心。出于我已经说过的原因，对此进行健康的讨论肯定只会增强VS Code的UI / X的更大目标。

ianwesterfield 于 2016-01-29

👍1

我也想插话，只是说我认为我根本不觉得“肚脐注视”正在发生。这个问题的发生时间部分上是错误的-11月19日没有时间将它放到12月甚至1月的任何地方，具体取决于计划的进度。另外-再次开始的对话比随机实施选项卡更重要，因为用户希望这样做。

我确实同意ianwesterfield的观点，即工作文件界面不是理想的，并且水平空间比垂直空间更多。在管理工作文件方面，vscode当前的弱点是海量文件列表和许多要切换的文件。
当您开始在16个不同的文件中跳动，然后能够管理它们属于哪个拆分编辑器时，工作文件将很难被使用。也就是说，将工作文件列表拆分为两个不同的部分将是一个合理的解决方案。

但是，史蒂文克（Stevencl）提出了一个使我非常高兴的论点。 “完全有可能在经过几轮设计和研究之后，我们最终引入了选项卡。但是，只有在知道这是改善用户管理其工作文件和资产的方式的最佳方式时，我们才能这样做，但最终不会使UI混乱。” 通过实际尝试新事物，可以实现改进。

管理拆分窗口的更简单方法已经是一种改进。我可以对工作文件进行论证，因为管理窗口始终可以位于同一位置。当您要重新排列2-4个拆分时（更高分辨率的屏幕+原子=必要时可进行水平和垂直拆分），管理标签会更加省力。因此，有一种可能的解决方案可以保留工作文件界面，而将其扩展为更加复杂。

mikewl 于 2016-01-29

谢谢，我感谢有机会进行这次对话。

@ianwesterfield ，您对工作文件的@kfranqueiro都已突出显示。当前的体验绝对不是期望的体验。

尽管从事Visual Studio设计已经有很多年了，但是我已经看到选项卡可能会导致UX问题。我花了18个月的时间在Visual Studio中进行预览选项卡的工作，这是为了减少@bpasero上面描述的“选项卡地狱”问题。

但是，我们希望避免进入需要这样做的位置。因此，我们希望继续进行深入的设计探索，以发现可供我们使用的选项，然后再决定一个。就像我之前说的，很可能我们以制表符结尾。如果这样做，我们将知道这是我们可以创建的最佳方法，它将为管理文件和其他代码资产提供丰富的经验。

感谢您对我们在VS Code中管理文件的方式所遇到的问题的所有见解和描述。

stevencl 于 2016-01-29

@stevencl ，有趣的是您应该提到预览选项卡-我喜欢它。默认情况下，VS Code，Sublime，Atom，方括号（通过扩展名）等具有这种预览功能非常好。

我非常高兴，Microsoft通过使该项目保持开放状态，使我们有机会参与正在进行的设计讨论。如果用户仅在重新设计“开始”菜单时才有这种声音，则Windows可能不需要另一个发行周期即可最终在Windows 7之后大量上线。

ianwesterfield 于 2016-01-29

经过几轮的设计和研究，我们最终有可能引入标签。但是，只有在了解到这是改善用户管理其使用的文件和资产的方式的最佳方法之后，我们才会这样做，但最终不会使UI混乱。

自从我打开这个似乎已经浮出水面的问题以来，我想补充一点，我认为这一评论是令人满意的。我宁愿怀疑会出现选项卡，但我完全支持探索新的想法，而代码是实现此目的的绝佳平台。我喜欢你们到目前为止所做的工作。
就是说，请记住，我们确实想使用它，并且我越早可以将其用作我的主编辑越好，因此，如果您能给我们提供熟悉的（仍然轻巧的）体验，我将不胜感激。我们现在可以高效地使用并感到宾至如归，就可以继续工作。然后，您可以花所有的时间探索新的视野：)
只是我们热切地等待代码到达不可思议的极限，以便我们可以全时间采用它。对我来说，制表符是我唯一的可用性投诉，本机编译和调试是我唯一的技术难题。

我不是唯一一个沉迷于Visual Studio的疲惫和痛苦的Windows用户。救赎只是我们无法掌握的几个小问题和特征，它正在迅速发展，我非常感谢有机会参与并以这种可见性观看节目。

可悲的是，Windows仍然是最糟糕的开发平台/生态系统，却拥有最好的开发环境，而且这种情况已经持续了15年之久。真奇怪。
我不知道为什么，但是对于我来说，开发环境（生产力）似乎在平衡中胜过了生态系统，但这是一个痛苦的平衡，当我可以在Linux中完全使用VS时，我会像猪一样开心-时间！我们是如此接近！
我知道你们认为这是探索新领域的一种手段，这绝对是很酷的，但是就短期而言，我们真的只想在Linux上使用VS（如果您采用这种方式，则选择osx），就像我们梦a以求的那样。这些年来，我们终于可以结束我们的苦难！ ;）
</dramatic_commentary>

TL; DR的探索工作非常好，我有信心您将致力于生产最好的最终产品，但与此同时也许又安全又熟悉的解决方案？

TurkeyMan 于 2016-01-29

+1标签。问题-为什么不从Visual Studio Bundle中删除它呢？看看会发生什么...

lordgreg 于 2016-02-03

+1标签页！请在以后的更新中实施。

launchpadinteractive 于 2016-02-05

运行的假设似乎是“在大多数情况下，[tabs]增长得如此之快，以至最终您什么都看不到”。我想挑战这个假设。我将标签用作当前感兴趣文件的可见索引，并且随着时间的推移，我会主动管理该索引。可见性很重要：我经常参考物理标签来重新定向自己。使用工作文件，我失去了查看和操作该索引的能力。例如，似乎没有办法通过键盘从“工作文件”中删除文件。感觉就像我在与编辑战斗。请添加Sublime Text样式标签。

peterbourgon 于 2016-02-08

👍4

虽然我同意VS Code现在可以在没有选项卡的情况下正常运行（自开始以来就非常有效率地使用它），但我也同意上面的一些评论，建议将选项卡作为选项（默认情况下可能被禁用），并让用户决定是否要使用选项卡或不。

每个人都是不同的，因此有一个选择会很棒。即使没有它们我也可以正常工作，但我不介意添加它们，并且可能会使用它们-使用VS full太多年了。听起来好像他们已经在积压中了-谢谢！

DanWahlin 于 2016-02-15

+1标签。使用VSCode将近一年，我非常喜欢它。但是仍然会错过选项卡，尤其是在使用调试或搜索或git左侧部分时。制表符可帮助您避免思考您以前一直在哪个文件中包含代码。我相信用户管理选项卡及其顺序时要牢记选项卡的位置，该位置可以与他们正在使用的源代码关联。分割的编辑器选项卡也可以保持这种意图。

Ctrl + tab是按键操作，而tab是视觉操作，这要快得多。

korzio 于 2016-02-19

如果VS在管理“工作文件”方面不是那么糟糕，我可能会没有标签。我经常打开文件只是为了引用内部文件，而没有实际对其进行编辑，但是VS不会将这些文件放在我的工作文件列表中，而我肯定会在选项卡式环境中打开一个选项卡。

再加上一个事实，当您关闭一个文件/将一个新的“工作”文件放在一个焦点上时，文件浏览器将移动到打开的文件上，而不是停留在您的最后一个位置上，从而带来了非常混乱的体验。

我知道这些对您来说不是问题，因为“您已经使用了4年没有制表符”，因此Ctrl + Tab范围之外的任何内容都被视为使用该程序的一种怪异方式。

Growiel 于 2016-02-22

这必须是一项功能，并且默认情况下它是打开还是关闭都没有关系。几乎每个文本编辑器/ IDE都使用选项卡进行导航。也许有人认为这是一种更好的方法，但是对于我们大多数人而言，选项卡是高效，易于使用和熟悉的……显然，我们喜欢它们！将它们带出Visual Studio进行一个发行，以了解它们的重要性...（提示Metro风格的史诗般的开发人员崩溃），请考虑使用短期发行版的标签。这是阻止我们中的许多人全职采用VSCode的唯一方法。

jayrosen1576 于 2016-03-01

👍1

：+1：

alvarod-infocorp 于 2016-03-01

使用制表符，我的工作效率更高！我使用Atom的方式与使用Google Chrome的方式相同（第一个选项卡Ctrl + 1，Ctrl + 5等。Ctrl+ Tab，Ctrl + Shift + tab）。

工作文件使我的工作效率降低，使用后我总是感到有些沮丧。

因此，请实施标签。

MadSpindel 于 2016-03-01

👍3

标签将非常有用，+ 1

isvforall 于 2016-03-01

：+1：

alvarod-infocorp 于 2016-03-01

@MadSpindel “工作文件使我的工作效率降低，使用后我总是感到有些沮丧。” 1000％的人同意...这就像我们被迫在没有标签的情况下让某人发表观点或做某事。我们不喜欢它，如果您愿意，请使其对我们可选。

sitefinitysteve 于 2016-03-01

Visual Studio Power Tools有一个垂直显示选项卡的选项，我绝对喜欢。

roncli 于 2016-03-01

：+1：我同意@sitefinitysteve。如果团队坚持不使用标签，那么至少要改进扩展API，以便可以由第三方添加。

ddevault 于 2016-03-01

标签在这里很重要-我们必须退后一步来寻找另一个缺少的功能：

VSCode需要转储工作文件的非信息实现，然后添加功能以允许打开多个项目。我的工作是将客户端代码分为一个项目，将服务器端代码分为另一个项目。在大屏幕上，我希望打开两个编码窗口，最左侧有一个项目树。客户端代码在左侧窗口中，服务器代码在右侧窗口中。现在，在这两个项目中，我将处理多个源文件。在那些情况下，我想将它们作为在打开它们的相应项目窗口上方的选项卡进行引用。在客户端项目中，我可能有3或4个选项卡，在服务器端项目中可能有3个或更多选项卡。

该组织是有机的。整个工作树和多个项目显示在左侧。我可以通过代码窗口进行项目分离，也可以通过各自项目窗口上方的选项卡来处理或引用开源文件。

这对我来说是必不可少的工作流程。我目前正在Atom中完全这样做，但我喜欢VSCode，并希望看到在VSCode中复制的流程。为此，VSCode需要在相应窗口上方实现多个项目支持和选项卡。否则，它只是另一个小家伙的编辑，我不相信这一点。请。

riclf 于 2016-03-01

👍2

@riclf发现了它。

我通常从左到右打开3个垂直列，HTML，JS和CSS。

在Sublime中，我的所有html标签都位于第一列的上方，所有JS文件都位于第二列的上方，依此类推。这些标签具有上下文，并且我知道我不会在错误的列中打开错误的文件。

这在VS Code中几乎是不可能的，我只能通过两次使用“向侧面打开”来打开3列，并且如果关闭文件，则一列可以完全消失，这时我可以打开一个新列，但必须重新排序他们。如果我打开一个文件，它将在光标当前所在的列中重新打开，因此，如果我打开一个css文件，则必须确保光标在第三列中。真是气死我了。

更不用说工作文件部分在我的文件夹树中占用了垂直空间，这在我的笔记本电脑上是一个真正的问题。

微软团队的问题。如果您有拆分视图，应该如何知道“工作文件”中的文件与哪一列相关联？当标签是其各自列以上这很简单。

只是我的2c。

jon64digital 于 2016-03-01

习惯了工作文件，我的认知不适感为零。我爱他们胜过爱标签。 VSCode的UI处于正确的轨道。我不反对选择加入标签，但会建议选择退出标签。

工作文件是布局更好的标签（更多的滚动空间）。它们缺少“撕纸”和拖动功能，可以在将来添加。

JVimes 于 2016-03-01

👍1

作为mvim用户，我打开了多组TDD文件，并在它们之间进行制表。例如，我进行角度+测试，服务器+测试，黄瓜或行为+脚本。我不想使用Tab键访问单个文件，而是使用打开文件的组合访问。我使用VSCode进行了3个月的Typescript项目，因为它确实具有同类最佳/惊人的Typescript支持。但是，当我转到一个非Typescript项目时，我发现我将其通用搜索，导航和替换功能直接与mvim进行了比较，很遗憾地说我迅速（即即刻）恢复了我的前任编辑。我有一个27英寸的Apple Cinema显示器，如果可能的话，它将显示更大的显示器。我有足够的空间容纳很多标签和文件对，并且没有令人信服的理由限制编辑器使用该空间我不想一次只处理一个文件-我想打开多个文件，并跟踪选项卡之间的流向。

jtosey 于 2016-03-01

两周前，我再次尝试了Visual Studio Code。当我整理了一些文件时，我实际上感到非常惊喜。但是当我开始处理一个实际的（大型）项目时，打开了多个文件，缺少选项卡变得非常烦人。 _工作文件_只是不适合我，这使我放慢了速度。 3天后，我对此非常恼火，以至于我回到了Sublime Text。我在工作时有两个24英寸屏幕（Windows），家里有一个27英寸Mac，可以轻松打开20个选项卡，仍然可以区分哪个文件。在我的情况下，很多屏幕空间都用于选项卡。 _You_已经显示了在编辑器中打开的文件的文件名。文件名右边的所有空间均未使用（窗口右边的图标除外），并可以用选项卡填充（Sublime Text也是如此）。我说给用户选择使用_Working Files_和/或文件选项卡的选项。现在，我将切换回Sublime Text和Visual Studio Enterprise的组合。添加标签后，我会重新考虑。

sjee 于 2016-03-01

👍1

对于Working Files选项，我必须切换侧栏（因为我将其隐藏起来以获取扩展的代码视图）以选择文件。 Ctrl+P和Ctrl+tab选项也不友好。

我知道你们正在为此尝试不同的方法，但是您已经提供的选项并不友好。抱歉。

nagpuregajanan 于 2016-03-02

请为此提供扩展，以便用户有机会使用标签，而不必强迫他们使用工作清单。我非常讨厌工作文件功能，它使我缓慢切换文件并偷走了我的工作效率

devsoft 于 2016-03-02

当我刚接触VS Code时，我真的错过了标签。然后我发现了ctrl + Tab，我不再需要它们了。

janmarek 于 2016-03-02

👎1

我几个月来一直在尝试使vscode（在大多数方面都很出色）成为我的主编辑器，但是缺少制表符一直困扰着我并损害了我的工作效率（我是积极管理打开的制表符集的人之一在其他编辑器中）。 Ctrl + tab不能代替选项卡。

显然，vscode团队对此持偏见，并且目前旨在“说服”用户他们确实不需要标签。但这是导致从Windows 8中删除“开始”菜单的相同类型的想法（我们都知道这是如何结束的）。

pesho 于 2016-03-02

👍1

@pesho就是这样！

WebPraktikos 于 2016-03-02

现在已经完成了代码折叠，这是用户语音中的首要问题。在继续权衡社区反馈，用户体验测试等方面的同时，我们还在内部权衡许多选择。感谢大家在此进行的讨论。很有帮助。

waderyan 于 2016-03-02

大概是我大约一年前第一次打开vscode并在几分钟后就关闭它的唯一原因。而且您仍然没有标签。希望它会很快出现，所以我可以使用它。它是开源的，来自Microsoft的人们需要改变主意（这就是他们现在打算做的，不是吗？）并听取社区的意见，而不仅仅是“我们在内部使用此工具，我们不需要标签bla bla”

pleerock 于 2016-03-02

👍1

@pleerock您甚至不尝试使用IDE，因为它没有选项卡？！（哦）weeeweweweweeweww。他们不希望添加选项卡，因为选项卡是没有意义的，冗长的选项通常在增加Windows chrome空间的顶部宽度时没有任何价值。这些替代方案提供了更多的元数据，易用性和更快的导航。

ghost 于 2016-03-03

👎4 👍2

使用选项卡，我选择哪些文件保持打开状态。无论是CTRL + tab还是“工作文件”，如果我打开一个文件以在其中查找一些代码，然后切换到另一个文件以使用上述代码，那么我无须返回到我的第一个文件，而不必重新导航到资源管理器中的文件。

我知道我有3个编辑器，但是有时候我不想用我的仅查找代码文件覆盖其他2个。

如果打开文件时它保留在不同的文件历史记录中，那么没有选项卡也可以。也许如果文件已打开超过5s，则应在CTRL + Tab中输入一个条目。

Growiel 于 2016-03-03

@ 4tron是的，这对我来说是正确的，因为我想使用对我来说很方便的IDE。对于失去标签的人来说，毫无意义且安全的空间（可能他们正在使用上网本，并且没有足够的空间容纳很少的额外像素=）；对于其他人来说，这样做很方便并且可以提高工作效率。任何好的软件都应该可自定义，并具有隐藏/显示面板的能力。 “节省空间”是没有争议的。引入标签+添加显示/隐藏标签的功能（如果某人确实需要，则=）），它们是最好的选择。无需打开新的美国或进行错误的创新，无需在这里学习最好的IDE，这些年来使UX变得越来越好，例如intellij，visual studio等

pleerock 于 2016-03-03

这真的很简单-只需将其设为“首选项”标签或不使用任何标签即可。选项卡打开时，没有工作文件；选项卡关闭时，没有工作文件。那是天才！ ;）

我，我是个标签生。我发现工作文件非常有限且不直观，并且占用了项目树上的垂直空间。但是，如果我们不能打开一个以上的项目，这并不重要。 :(

riclf 于 2016-03-03

我认为偏好也可以。

我也想到了一种增强工作文件系统的方法。您应该使用制表符作为历史记录。
例如，如果您在左侧窗口中打开4个文件，然后在选项卡行中打开第5个使最早的修改文件，则该文件将消失并仅作为工作文件中的“修改文件”返回。

您也可以使其变得智能，系统还可以优先考虑先消失后未保存的文件的优先级。

事实是，即使标签出现膨胀，标签也是如此实用。您应该考虑使用制表符的方法，但要限制它们的数量。

通常，我会打开几天未编辑的标签。这通常是使它膨胀的人。

Guema 于 2016-03-03

+1

KevinFinckIDS 于 2016-03-03

我有一个4K屏幕，没有标签可以水平移动，这真的使我无法使用VsCode

mustafaakin 于 2016-03-03

顺便说一句，我想澄清一下，我不仅想要标签，还想要标签集。作为Mac上的全栈mvim TDD开发人员，我认为是上下文相关的。 html + css，角度+测试，节点+测试，黄瓜+测试步骤。在移至下一个上下文（TDD样式）之前，我通常在单个上下文中处理几行代码。使用mvim时，我不仅可以非常快速地在这些上下文之间切换（使用与Mac Terminal，Mac Finder和Safari或Chrome相同的键序列），而且还受益于自动打开配对文件的宏，以便从角源文件，我可以自动打开相应的测试。这是一种非常有效的工作方式，可以让我的手指一直放在键盘上。

jtosey 于 2016-03-03

👍2

如果我找到一个IDE，可以通过切换一个选项卡来打开彼此相邻的“关联”文件，例如，当我打开button.html时，它将打开它旁边的button.scss第三帧，我再也不会使用其他IDE。

我知道它永远不会发生，而只是说出来。

jon64digital 于 2016-03-04

好了，那么，您应该使用mvim！ http://www.vim.org/scripts/script.php?script_id=1567命令：AV打开关联的文件（A关联）。

jtosey 于 2016-03-04

@jtosey谈论的正是我在这里说的。我使用窗格来组织一组相关文件。大多数选项卡管理都涉及在切换上下文时使那些相关文件彼此相邻。

Trillinon 于 2016-03-04

👍1

+1

sudogooglex 于 2016-03-05

同样在这里，会喜欢标签。

rogierlommers 于 2016-03-05

我刚从Atom切换到VSCode，注意到使用了一段时间后，它的组织和清理感觉令人惊讶。原因？标签不要过多！实际缺少制表符是使此体验如此流畅的原因。我的主要文件导航是Command-P菜单，它使我可以快速跳转到任何文件。

kevinchiu 于 2016-03-05

👍6 👎2

VS选项卡非常完美，请带上选项卡，将选项卡取消固定到单独的窗口中也将非常有用！
谢谢vscode :)

a8775 于 2016-03-06

实际上，我是否想将VSC用作通用文件编辑器还是仅将其用作源代码编辑器就很好奇。

在某些情况下，绝对需要使用标签栏。

在多个标签之间快速切换。
对我来说，一个常见的情况是我需要按文件的形状比较两个或多个文件，例如比较简体中文和传统文件。差异无法解决问题，因为它们是不同的字符。唯一的方法是在选项卡之间快速切换，以查看您的眼球中是否有任何遗漏的单词。使用ST和我可以使用Alt-NUM切换选项卡，但是在VSC中，唯一可能的方法是使用多个Ctrl-Tab或鼠标快速移动并单击。
长且难以键入的文件名。
使用Ctrl-P在文件之间切换还不错。但是，一些共享长期修正的文件名又如何呢？一些不是英文的名字怎么样？考虑一下您将在Ctrl-P上花费多少时间在青年急着买房的原因（上）.md和青年急着买房的原因（下）.md之间切换？

我会说，编写代码时不会遇到任何情况，但是作为通用编辑器，这是一个严重的问题。

msg7086 于 2016-03-07

@ msg7086我不确定第一点，但是对于第二点，您不能ctrl + p然后键入.md留下两个选项，然后只是ctrl + tab选择一个想？不确定我是否正确理解了这个问题

ghost 于 2016-03-07

@ 4tron感谢您的答复。但是，仅当我只有2个具有该类型的文件时，您的方法才有效。实际上，人们可能会在一个目录中处理大量文件。成像我正在写一个博客，其中包含50个markdown格式的帖子，文件名用中文，韩语或阿拉伯语等不同字符。我遇到的实际情况实际上是一些带有CJK名称的字幕文件，其中所有字幕文件都是*.ass ，因此Ctrl + P扩展名不能很好地工作。

msg7086 于 2016-03-07

真的很感谢，如果可以实现

shivateja-madipalli 于 2016-03-08

开发人员已经习惯了，请优先考虑。

binbsr 于 2016-03-08

+1标签。请实施标签。

kulbir 于 2016-03-08

+1标签页！

tonholis 于 2016-03-08

我也投票赞成添加标签。

nvivo 于 2016-03-08

+1

harold-b 于 2016-03-08

+1

jpgarcia 于 2016-03-08

+1

lucasmahle 于 2016-03-08

我们需要尽快的标签。

amnesia 于 2016-03-09

我想念标签。我一直在寻找他们，希望能快速地引用两个或三个不同的打开文档。

有什么大不了的？

工作文件区域被锁定在高度上，这与太多的选项卡一样是一个问题，只是要灵活地进行管理（此处没有鼠标或滚轮）。标签可以轻松放逐，从而为用户提供打开文件堆栈中的下一个文档。
Code中的Explorer列比Sublimes宽得多，有时并排运行两个应用程序以节省空间时，有时希望将其最小化（例如，Unity在左侧，Code在右侧）。制表符不需要任何空间的节省，代码已经有一个不错的空白区域，可以在其中移动。
制表符可以简化操作并节省空间，因此无需用户体验研究。它们使用起来很快，我们都喜欢它们。

请给我们选项卡式文档管理:)

HawkenKing 于 2016-03-09

+1，我。

davidpmccormick 于 2016-03-09

+1

gbrlmza 于 2016-03-09

+1

ucirello 于 2016-03-10

VSCode是一个出色的编辑器，并且与Git和Nodejs都有很好的集成点。我不将其用作主要开发IDE的主要原因是因为它不支持选项卡。

kpiascik 于 2016-03-10

同样在这里。这是使我无法使用的一件事。
10分钟捷运。 2016年om 15:18 schreef Konrad Piascik < [email protected]

VSCode是出色的编辑器，并且与Git和
Nodejs。我不将其用作主要开发IDE的主要原因
是因为它不支持标签。
-
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -194867036。

rogierlommers 于 2016-03-10

鉴于它应该很容易实现，因此看到在该问题上有如此之多的推翻有点令人惊讶。至少要使其成为一个选项或通过扩展来使用（如Brackets一样）。

如果确实添加了此内容，请添加以下内容：

关闭功能，例如Google Chrome。（总是让VS的标准版本感到恼火）。
-“关闭其他标签”
–“关闭右侧的选项卡”。
打开右侧或左侧选项卡的选项。（VS有时更改了默认设置，但随后添加了一个更改选项）

jmlivingston 于 2016-03-10

标签工作。他们无处不在，人们已经习惯了。当前文件列表是不直观的。每天使用VS Code 2个月后，几乎每次需要切换文件时，我仍然会寻找选项卡。其他所有编辑人员都将继续使用选项卡这一事实为不同的东西变得直观提供了巨大的障碍。

在我的团队中，人们一直对此表示抱怨，以至于有些人更喜欢使用不支持任何打字稿的Sublime，然后使用VS Code。

我不反对UX研究来找到一种处理打开文件的“更好”的方法，但是请不要再一次使Office功能区惨败，这花了五年的时间和多个版本才能发明出另一种方法来完全一样。

nvivo 于 2016-03-10

-1

关于为何反对标签的一些注意事项：

在选项卡上花费的任何时间都将花费在对编辑器进行其他改进上。
我一直在强迫自己变得更像键盘突击队员，而没有制表符很有帮助。因此，即使我本人还不在那儿，我还是从自己的角度出发进行争论。
与之前的内容相关，这让我想起了Gmail何时发布，我不得不说服人们标签优于文件夹。有些人只是无法处理它，而仍在晃动他们的AOL / ISP电子邮件帐户。我认为MS应该站在这里说“我们只是认为这是做事的更好方法”。
如果我有任何建议，那将是为什么没有选项卡的一个初步解释，以及在没有选项卡的情况下浏览编辑器的示例。

WhatsThatItsPat 于 2016-03-10

👍4 👎1

好吧，这是一个折衷方案-在“首选项/选项”中使选项卡可见或不可见。

我认为其他改进不会花费时间，因为我确信他们在此开发人员中拥有多个程序员。我也喜欢键盘突击队。如果实现了它们，那就不要使用它们，但是为什么要禁止那些在工作流程中偏爱选项卡的人使用它们。

无论如何，没什么大不了的。在等待VSC决定要做什么时，我已移回Atom。我发现一个标签对于一个大型项目的工作流程至关重要，并且能够打开多个项目文件夹。

riclf 于 2016-03-10

我一直在强迫自己变得更像键盘突击队员，而没有制表符很有帮助。因此，即使我本人还不在那儿，我还是从自己的角度出发进行争论。

正如我之前在该线程中所建议的

kfranqueiro 于 2016-03-10

拿着电话！我得到了答案！这是完美的！准备？我们不需要标签。让我们通过一个简单的选项扩展工作文件，使其在编辑器顶部的

jayrosen1576 于 2016-03-11

😄2

我实际上更喜欢现在的方式-用于打开文件的面板和侧面带有“工作文件”的类似列表的文件选择器。当我使用Atom时，我讨厌每次我快速查看一个文件时，它将打开一个新标签页，并且在几分钟之内，我的标签栏就充满了无用的标签页。

所以我对此是-1。但是我仍然希望看到窗户的对接。

felixfbecker 于 2016-03-11

我刚从Atom切换到VSCode，注意到使用了一段时间后，它的组织和清理感觉令人惊讶。原因？标签不要过多！实际缺少制表符是使这种体验如此流畅的原因

这个。 100％同意。

felixfbecker 于 2016-03-11

我实际上更喜欢现在的方式-用于打开文件的面板和侧面带有“工作文件”的类似列表的文件选择器。当我使用Atom时，我讨厌每次我快速查看一个文件时，它将打开一个新标签页，并且在几分钟之内，我的标签栏就充满了无用的标签页。

我明白了，这就是为什么我们要求提供_additional_功能而不是替代工作文件的原因。我一辈子都无法理解为什么不能将两者都包含在编辑器中。我是认真的看看这个线程中有多少个选项卡！这不是_嘿，我希望按钮为blue_方案。这对于大多数想要此文本编辑器中的选项卡的人来说是一个障碍（顺便说一句，这是优于Atom和Sublime的方式）。我在两面都得到了有效的论据，但我只是不明白为什么选项卡和工作文件不能包含在打开任何一个的选项中。大家都赢了。

jayrosen1576 于 2016-03-11

@ jayrosen1576可能的问题是，没有人真正提出过有关其外观的深入建议

标签栏是否应该位于所有窗口的顶部？
当您有多个文件并排打开或在以后的版本中甚至水平拆分时，单击选项卡如何工作？
活动文件的标签会始终突出显示吗？如果调试控制台集中精力怎么办？
如果启用选项卡设置，是否会因为多余而删除工作文件部分？
在不同文件夹中重复的文件名呢？
选项卡和面板的重复关闭按钮怎么办？
关闭面板会关闭标签吗？
当您像在Atom（urgh）中那样打开文件时，或者仅当像对工作文件那样进行编辑时，选项卡会立即显示吗？

这些都是开发团队必须花费时间的问题。尽我所能，我想不出一种比工作文件列表更优雅并且不会造成混乱的实现。

felixfbecker 于 2016-03-11

以下是有关外观的建议：

1）下载Atom
2）开放原子
3）查看标签
4）在VSCode中实现

jayrosen1576 于 2016-03-11

😄6

@ jayrosen1576认真吗？我对Atom的实现提出了一些有效的关注，还提到了Atom根本没有的问题，因为它没有工作文件的概念。

再说一遍，您的个人资料照片说明了一切。

felixfbecker 于 2016-03-11

标签栏是否应该位于所有窗口的顶部？
答：是的。尝试Atom中的标签
当您有多个文件并排打开或在以后的版本中甚至水平拆分时，单击选项卡如何工作？
答：选项卡显示在每个窗格的顶部。尝试使用Atom中的标签。
活动文件的标签会始终突出显示吗？
答：是的。尝试使用Atom中的标签。
如果调试控制台集中精力怎么办？
答：与调试控制台现在集中处理并排打开两个文件的结果相同。
如果启用选项卡设置，是否会因为多余而删除工作文件部分？
答：仅当您禁用工作文件时（作为选择）
在不同文件夹中重复的文件名呢？
答：选项卡包含部分路径。尝试使用Atom中的标签。
选项卡和面板的重复关闭按钮怎么办？
答：面板上没有关闭按钮。尝试使用Atom中的标签。
关闭面板会关闭标签吗？
答：是的。尝试使用Atom中的标签。
当您像在Atom（urgh）中那样打开文件时，或者仅当像对工作文件那样进行编辑时，选项卡会立即显示吗？
答：仅当您启用该选项时（Atom中的usePreviewTabs = false会关闭此功能）。否则，双击将它们在选项卡中打开。尝试使用Atom中的标签。

jayrosen1576 于 2016-03-11

@felixfbecker因为此产品带有Visual Studio名称，所以应该有可选的选项卡，并且它们的行为应与其他Visual Studio产品中的行为相同。

它表示当您提出一些与个人资料图片一样的内容，以回应对您所关心问题的有效答案时，有关您角色的角色。

ianwesterfield 于 2016-03-11

拿着电话！我得到了答案！这是完美的！准备？我们不需要标签。让我们通过一个简单的选项扩展工作文件，使其在编辑器顶部的标签中水平显示！呜呜！解决了不创建标签的问题！

@ jayrosen1576这实际上并不能解决全部问题，因为正如我之前说过的（并再次在字面上直接在您的注释中提出），不只是选项卡的视觉外观不同，而是行为。就像我在这里的第一条评论中所说的那样，您也可以在Sublime Text中获得“边栏中的选项卡”，但是它仍然与工作文件不同。（IMO更好。）

kfranqueiro 于 2016-03-11

@kfranqueiro我完全同意。我只是狡猾。这个选项卡是一个非常愚蠢的论点。如果VSCode只是具有Atom选项卡的选项卡功能，并且可以选择隐藏它们（即使默认情况下），那将是完美的。我认为我们都在要求同一件事。我只是不明白为什么不能同时将两者都关闭。

jayrosen1576 于 2016-03-11

坦率地说，讨论选项卡是否适合文本编辑器只是愚蠢的事情。这不是一个新概念。只需实施并将它们保留为可选。使其扩展，并使其成为否。 1扩展直到人们意识到这是基本功能，没有它没有意义，就像VS大写菜单选择一样。

nvivo 于 2016-03-11

😄3 👍2

@nvivo我自己不能放。整个讨论似乎很愚蠢。

jon64digital 于 2016-03-11

就像VS大写菜单选择一样。

@nvivo您是否尝试过此扩展程序？没有菜单选项，但您可以设置一些键盘快捷键。效果很好。

https://marketplace.visualstudio.com/items?itemName=wmaurer.change-case

jayrosen1576 于 2016-03-11

如果您不喜欢这种讨论，请继续。读取该线程是完全可选的！

riclf 于 2016-03-11

当然，阅读是可选的，但是它的存在似乎支持以下观点：在VS Code中添加选项卡是可选的，我们应该进行辩论。以下问题的简单民意调查。

如果不尽快添加选项卡，您将继续使用VS Code吗？是/否

可以表明，如果不增加微软的潜在用户群，微软将失去他们的很大一部分。这意味着从商业角度来看，即使他们自己不需要该功能，如果他们不这样做也将是商业自杀。嗯，这次谈话分散了人们的注意力，也没有必要。

话虽如此，我们谈论的是同一家公司，但仍未在其浏览器中添加扩展程序。所以我想一切皆有可能。

认真地说，现在唯一的讨论应该是关于实现选项卡的最佳方法。人们是否想要该功能不再是一个问号，因此让我们将讨论的重点放在更具建设性的事情上。

jon64digital 于 2016-03-11

浏览器扩展？活动中... NVM。

msg7086 于 2016-03-12

诚实，我认为没有理由使用标签。对标签的热爱实在令人难以置信。在完成实际工作方面，快捷键可以完成所有必要的工作，包括通过正则表达式进行搜索，更多的元数据和更好的工作流程。他们提供了一些我熟悉的基本的深奥需求。我觉得这只是一个推动作用，旨在了解ms是否将为社区服务，看看它们是否真的在改变。尽管不如vs问题中的整个大写文本那样毫无意义。

就前面所说的而言。

“我认为其他改进不会花费时间”

我个人认为这样做，例如在文本编辑器窗口上创建可扩展性功能，以便可以为任何需要标签的人进行扩展。我很确定vscode的整个想法是使它尽可能地最小和轻巧，最终用户可以添加扩展或扩展它。

ghost 于 2016-03-12

👎2 👍2

@ 4tron ，当然有邪恶社区的阴谋在这里测试Microsoft！不总是一个吗？

如果选项卡有意义，我们将看到其他编辑器正在使用它们。而且，如果这是组织多个开放内容的一种好方法，也许其他需要组织多个开放内容的软件（例如，浏览器）也会使用它们。但是，它们当然没有，因为它们没有道理！您能想象人们一直在使用的东西，例如使用标签的浏览器吗？废话！

我说让我们放心。首先，让我们拭目以待，看看是否还有其他优秀的编辑器支持此新功能，这样我们就不会浪费时间和精力在实际上不起作用的东西上。让我们检查一下Visual Studio，intellij，eclipse，atom，sublime，monodevelop，notepad ++或具有大量用户基础的任何其他项目。一旦至少有一些编辑器支持此功能几年而不用其他功能替代它，那么就会有迹象表明这是一个有用的功能。

但是，让我们不要超越自己。我们需要像问题跟踪器这样的工具，使人们可以直接表达这种愿望，甚至可以让其他人投票，因此我们可以确保我们不会无所作为！只有当它成为存储库中最需要的功能之一时，我们才能采取措施。然后我们将知道，这不仅是一种趋势，而且人们发现它对他们的日常工作很有用，并且在这里也希望使用该功能。

但是直到那一天，让我们耐心等待。文本编辑器是崭新的事物，实际上没有人知道需要什么样的功能。

nvivo 于 2016-03-12

😄1 👍1

哎呀，好笑！

Op za 12捷运。 2016 om 11:57 schreef Natan Vivo [email protected]

@ 4tron https://github.com/4tron ，当然还有阴谋
邪恶社区在这里测试Microsoft！不总是一个吗？
如果选项卡有意义，我们将看到其他编辑器正在使用它们。如果它
是组织多个开放内容（也许是其他类型）的一种非常好的方法
需要组织多个开放内容的软件，例如
例如，浏览器也将使用它们。但是他们当然不会
因为它们没有意义！你能想象人们使用所有
时间像浏览器使用标签？废话！
我说让我们放心。让我们首先等待，看看是否还有其他好的编辑器
支持此新功能，因此我们不会在某些事情上浪费时间和精力
那实际上是行不通的。让我们检查一下Visual Studio，IntelliJ，Eclipse，
原子，崇高，monodevelop，notepad ++或任何其他具有
大量的用户群。这些编辑者至少有一次支持
这项功能已经使用了两年，而没有用其他方式取代，
那么就会有一些迹象表明这是一个有用的功能。
但是，让我们不要超越自己。我们需要像
问题跟踪器，人们可以在其中直接表达这种愿望，甚至可以让
其他人投票，所以我们可以确保我们没有这样做
没有！我们必须采取最严格的行动之一，我们才能采取行动
存储库中的功能。然后我们将知道，这不仅是一种趋势，
但是人们发现它对日常工作很有用，因此希望在此处使用该功能
太。
但是直到那一天，让我们耐心等待。文字编辑器是崭新的事物
实际上没有人知道需要哪种功能。
-
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -195715795。

rogierlommers 于 2016-03-12

@nvivo您现在真的在将浏览器与文本编辑器进行比较吗？我了解您在这里对讽刺的过度使用，这很好。我要说明的重点不是选项卡是否有用之一。我喜欢lightwieght /最小编辑器的想法。这只是我的意见，我喜欢基于用户的喜好为用户扩展编辑器的想法。这就是我想要vscode进行的工作。然后我们可以将讨论移到“为什么还没有开发人员为此创建扩展..哦，也许我应该因为我喜欢制表符，并且我希望在其中这样做，而vscode可以做到这一点，所以现在我有了一个文本编辑器类似于我的浏览器”

ghost 于 2016-03-12

@ 4tron在我看来，他也正在将文本编辑器与文本编辑器进行比较。
我认为他们在使vscode可扩展方面做得很出色，但是我坚决认为标签应该是现成的功能。这个概念“哦，您喜欢使用的所有其他软件一样的选项卡吗？谷歌搜索问题，找到建议说明如何安装适当的用户提供的扩展程序，您就很好了！” 不飞。我想大多数用户只是希望标签存在，而我强烈怀疑有很多人会认为您会通过安装扩展找到标签栏。我敢肯定，这是任何其他软件都没有的先例。人们为什么会考虑这样做？

TurkeyMan 于 2016-03-12

👍2

@TurkeyMan
他的言论始于与浏览器的比较。

我们在这里谈论开发人员。我确实认为，如果他们希望使用制表符，他们将拥有主动权。很抱歉，我反对这个想法，但是我没有看到有效的原因标签，我一直都在alt + q vs.我只是看不到任何附加值。这是我的个人观点，也许是因为我不了解制表符应该是有用的废话开发人员。我认为这次对话很冗长，我个人希望将vscode作为隔离的外壳打开，以用于几乎完整的定制甚至基于业务的模型。有人可以在诸如drupal开发或wordpress开发之类的集中程度上增强定制，编辑器的建立是基于用户代码库的生态系统。我也觉得这是一个更好的问题。

ghost 于 2016-03-12

一切扩展的不利方面是，您最终会在它们之间产生怪异的，不需要的交互。在vs代码中，已经在Smart File Reopener之上使用GitHistory导致了奇怪的文件关闭问题。

选项卡之类的基本知识应该是开箱即用的。现在，正如其他人在该主题中所要求的那样，在选项卡中打开选项卡组或在选项卡之间创建关系是讨论扩展的地方。

ianwesterfield 于 2016-03-12

👍1

@ 4tron ，这很有趣，但是我真的很认真。

您可以决定是否在文本编辑器中支持外部编译器服务。集成的任务运行程序很不错。

制表符不在此类中。标签就像窗口，按钮以及打开和保存文件一样。人们期望它不会在这里做出决定，只是让它们在那里并继续前进。这不是一个高级定制的东西，很少有人希望得到插件的支持，它们是_anywhere OS中的标准UI。人们已经习惯了它，这是有原因的，为什么其他所有可能的编辑器都不需要请愿书来添加它们。

这就是为什么讨论选项卡的好坏是愚蠢的。 VS Code不是一个UX实验，它是一个尝试为所有平台提供一个好的.NET编辑器。让这该死的事情对90％的人有用，您就会成功。

老实说，我对替代方案有您的意见，但是您只需要了解您是少数。相信要求这样做的大多数人只是想测试Microsoft的巨魔，这只是妄想。

nvivo 于 2016-03-12

👍2

关于调用ms是否会更改其在tabs上的立场的想法是不满意的，主要是因为对包含tabs的热情。由于没有选项卡，因此有人甚至不尝试编辑器。我很难理解这一点。别忘了它仍处于Beta版。因此，希望他们会添加标签（请选填）。

ghost 于 2016-03-12

@ 4tron我尝试了很多次，并且我不定期使用vscode，因为它似乎无法很好地扩展到大型项目，并且缺少选项卡是我认为很重要的主要实际原因之一。
当我编辑少量文件时，我主要将其用作轻型文本编辑器，但是一旦我要处理我们的大型项目之一，vscode就无法使用。缺少选项卡以及没有子项目（VS称之为“解决方案”）的事实是我目前所知道的唯一阻止者。

我只是想评论一下通过插件添加所有内容的想法。这是一个不错的目标；拥有一个很好的扩展框架很重要，但是我认为他们需要谨慎对待这个想法。
我使用VS，虽然它让我发疯，但我发现我很喜欢它，因为它具有很高的产品质量，这是我对MS产品的期望。我已经尝试了所有OSS替代产品（以及其他专有工具），它们似乎都在基本的可用性方面（尤其是在调试体验方面）不足。
我真的希望vscode的目的不是成为每个人都可以通过扩展将其随机入侵功能的轻巧外壳...已经有许多其他工具可以满足这种描述，我还没有发现另一个引人注目的工具。我想要的vscode是VS一直希望的。由专业UX设计师从可用性角度进行精心设计，并成为CROSS PLATFORM。

TurkeyMan 于 2016-03-12

我认为那些反对制表符的人可能会遗漏了重点。我（我们）不想要一个全有或全无的解决方案。我们只需要一个简单的选项即可打开外观和行为与常用Atom编辑器中的外观类似的选项卡（默认情况下可以隐藏它们）。如果您不喜欢它们，您将永远不会知道它们的存在。如果您这样做，则可以启用它们。对于那些从未使用过Atom和多窗格+选项卡体验的用户，我建议您在完全忽略它们的参数之前尝试一下。您可能不喜欢它们，但是您必须承认它们对我们许多人有用。如果不是因为VS Code出色的node.js调试功能，我将专门使用Atom。我不在乎工作文件。我认为它们可能很有用，但是它们不能很好地替代制表符，并且它们实际上并不是替代方法。这就像在说_您有一辆本田思域，为什么要一辆皮卡车？_尝试将1200磅的竹制榫槽地板装载到思域的后部，您会明白为什么的。两者都是车辆，但用途不同。

就像我之前说过的，从某个版本的Visual Studio，Edge或任何其他Microsoft产品中移除选项卡，然后查看响应。不会很漂亮我们都可以同时使用。我们要求选项卡是_optional_而非必需的编辑器组件。时间可以花在其他编辑器开发上吗？当然。关键错误修复和改进（阻止使用编辑器）应始终放在第一位。但是，我确定添加了许多功能，这些功能并没有达到关键的改进或修复的水平。因此，如果花时间在那些线程上，那么应该为该线程上的绝大多数功能都留出时间。

我们喜欢VSCode近几个月来的发展，我们之所以参与这个主题，是因为我们希望它成为最好的编辑器。这里没有消极的余地。我们都对开发人员想要/不想要的东西充满热情。没有人有错误的观点，但必须尊重这样的反对意见，而不能仅仅因为您认为它们是无效的而轻描淡写。

jayrosen1576 于 2016-03-12

👍4

我认为没有太多的“标签激情”。发生的情况是， @ bpasero声明“我不认为选项卡不是显示打开文件列表的好方法”和“到目前为止，我还没有听说过使用选项卡的充分理由”之后，人们会变得更加直言不讳向主项目提交者的请求。

我很沮丧地看到所有这些讨论，我有点生气，因为我每天在工作中使用VS Code，并且想要在Mac和Linux上拥有一个出色的.NET编辑器，而且我非常想念制表符，而我并没有得到“哇！这实际上更有用_”的时刻，但是这里的回答似乎是“ _您只是没有意识到我们创造了一些惊人的东西！花点时间并习惯它！_”。

以下是我每天使用VS Code几个月后看到的一些实际问题：

单击窗口中的关闭图标对我来说没有任何意义，但是将文件保留在该列表中-我必须不断不断地手动清理该列表，以得到一个列表，在该列表中，我只能看到我实际上正在使用的文件-以及这些文件我合作的对象不是我打开的最后一个或正在更改的那些，而是我想同时保持打开状态的那些
关闭一个未保存的文件并用标记将该文件保存在列表上对我来说是没有意义的-一天我多次执行某项操作，并且更改未反映在应用程序中，因为我关闭了该文件，而VS代码未询问我要保存它，这使我浪费时间
一次单击即可打开文件，但只需双击即可将文件放置在最近使用的部分中-因此，我不断打开未出现在此处的文件-然后，我的肌肉记忆力发现在文件中添加或删除空格更容易然后滚动到我正在查看的文件，然后双击它
我感到很烦人的是，除非将鼠标悬停在列表上，否则一旦列表填满就无法看到滚动条。现在，这很复杂，因为这就是UI在编辑器中的工作方式。但是，我知道该项目，并且我知道文件夹视图中必须有更多文件。我也知道代码的结构，所以我知道编辑器窗格中肯定还有其他内容。但是对于最近的名单，我一无所知。 “它已满还是我忘记打开该文件？我在一分钟前没有打开该文件吗？让我再次打开该文件...”

现在，我看到大多数问题都可以通过“ _oh”之类的参数来解决，但您遗漏了这一点，它是最近使用的文件列表，而不是打开的文件列表。您正在将其与选项卡进行比较，并且效果更好处理打开文件的方法。一段时间后，您开始..._”

我对此很高兴地回答：“ _这整个事情对我来说毫无意义，实际上使我无能为力。已经有一种解决方案可以在数十年内无处不在。问题，老实说，我不认为这种新的解决方案是更好的选择。我们能否拥有一些熟悉的，行之有效的并且我们都习惯的方法？谢谢您”

我知道所有这些听起来都是自大的。但是我敢打赌，这就是大多数人的想法，但要么太害羞，要么太客气了。

实验性UI非常适合作为替代方案，我全都可以在两者之间进行切换。但这是当前的强制实验，它阻止了最常见和预期的其他选择。就像Windows 8的“开始”菜单一样，此操作也无法顺利结束。

nvivo 于 2016-03-12

👍6

我对此很高兴地回答：“这整个事情对我来说毫无意义，实际上使我无能为力。已经有一种解决方案可以在数十年内无处不在。我不想修复从未有过的问题，老实说，我不认为这种新的解决方案是更好的选择。我们能否拥有一些熟悉的，行之有效的并且我们都习惯的方法？谢谢”
...
就像Windows 8的“开始”菜单一样，此操作也无法顺利结束。

我完全同意。

jayrosen1576 于 2016-03-12

因为代码折叠曾经是功能最受好评的功能，所以tabs也是如此。 vscode团队让我们可以折叠。

如果考虑到vscode团队在微软不断加入开放源代码社区中令人欣喜的情况下，vscode团队包含顶级用户请求的良好记录，我将感到惊讶和失望。

ianwesterfield 于 2016-03-12

@ianwesterfield没错，它的选票数以千计的顶部请求的功能。这将会发生。该对话毫无意义，需要继续进行至“选项卡应如何工作？”

jon64digital 于 2016-03-12

我之前评论过选项卡的一种近乎完美的实现：Atom。它们易于组织，如果两个选项卡具有相同的文件名，则可以正确显示部分文件路径，并且在具有多个水平和/或垂直窗格的窗口中可以很好地工作（我认为这是VSCode的另一个必需功能）。如果VSCode具有与Atom相同的选项卡功能，那么我认为这将满足所有人要求的99％。而且由于Atom也是基于电子的，因此实现在VSCode中同样可以发挥作用。我不希望有任何模仿的解决方案，但是他们（Atom）在实现选项卡方面做得很好，在这方面，他们提供的是出色的解决方案。

jayrosen1576 于 2016-03-12

@ jon64digital也许只有我一个人，但我认为阻止这种对话发展的是一种沮丧感。即使3月31日的迭代中有6k +票和措辞含糊的参考，此请求仍未分配到积压中：

改善文档管理，编辑者的堆叠行为

感觉就像我们仍然需要反复证明选项卡的存在，更不用说它们的行为了。我想，至少该参考文献是消除采用障碍的三分之一，但现在是3月12日...

考虑到这一点，我认为如果他们至少将其分配给某人，我们可以放心使用@waderyan先前所说的内容，然后对话就可以开始发展。

编辑也许VS Code团队缺乏承诺是一个误解-自1月7日以来所有3月迭代计划都没有更新。

ianwesterfield 于 2016-03-12

@ jayrosen1576我同意-我认为可以通过扩展名解决未满足的1％用户请求（例如，在选项卡组中打开具有关系的文件等）。

ianwesterfield 于 2016-03-12

@ jayrosen1576 atom是否允许您链接文件，以便您可以拥有一个拆分视图，例如，该视图在第一帧中打开toolbar.html，在第二帧中打开toolbar.js，在第三帧中打开toolbar.css？

这只是一个例子，但绝对是理想的。上面的人说Vim可以做到这一点，但是我检查了Vim并出于多种原因不愿意这样做，但是选项卡听起来不错。

jon64digital 于 2016-03-12

@ jon64digital Atom默认情况下不执行此操作，并且我还不知道到目前为止有任何扩展（甚至是受vim启发的扩展），但这是我在上一篇文章中提到的扩展用例。

编辑指的是以上@jtosey的评论（在此帖子之前约9天）。

我个人可以看到这很烦人。有一半时间我不在乎视图-只是控制器，模型和客户端JS。如果每次打开JS都打开视图，我可能最终会发疯。

但是话又说回来，这就是扩展的妙处-如果我不喜欢它，可以将其关闭。

ianwesterfield 于 2016-03-12

在处理对UX产生非常强烈影响的功能请求时，我们通常通常会先在UX会议上花费一些时间来讨论实际实现的外观。在相当长的一段时间内，我们已经在议程中改进了文档管理，但是我们的GA列表中的其他内容只是具有更高的优先级（例如可访问性）。

我们将在本月GA发布后选择该项目，并开始讨论将来文档管理应如何工作。我们确实看到了当前工作方式的一些缺陷，并且知道我们需要改进它。我们认为，即使没有标签，今天UX的行为还是有些不直观的（Close Editor vs. Close File，事实是侧面编辑器与其他编辑器，工作文件和快速编辑器相比，行为有所不同）打开等）。

尽管标签的概念已广为人知，但我们认为我们不能仅在现有文档管理之上添加标签，而无需在此重新访问我们的概念。

我确实认为我们将在将来对文档管理的工作方式进行很多讨论，并且我认为我们有必要在必要时对这些概念进行全面检查。

bpasero 于 2016-03-13

🎉3 👍3

@bpasero在检查了另一个问题的代码后，我不明白为什么不能仅添加选项卡，或者为什么您需要更改哪些概念。如果您可以启发我们，可能会走很长一段路，或者这是对您原始帖子中思路的参考吗？

ianwesterfield 于 2016-03-13

@bpasero如果您详细阐述了所讨论的内容以及您认为哪些方法可以解决我们发布的问题，这是很好的。

PS：我不确定VSCode是否可行，但是像Roslyn，TypeScript之类的一些团队以及其他一些团队分享了他们的设计说明，它为他们的工作方式和下一步发展提供了很多背景信息，也使社区可以进行新的讨论，这样可能吗？

eyalsk 于 2016-03-13

👍1

@bpasero团队将认真考虑社区尝试添加标签的尝试。我不介意尝试，但我不认为任何人都想浪费时间，如果任何努力都会受到阻碍

我认为您的团队陷入困境，已经使这个小道消息进入了山峰。

含义：选项卡是文档管理更广泛概念的组成部分，而不是同义词。已经提出了其他问题，涉及vscode文档管理的其他领域。

ianwesterfield 于 2016-03-13

我们已经通过公开讨论了UX想法（请参阅https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Aux），我想我们会做同样的事情用于文档管理和标签。

我也认为我们不希望通过扩展来实现这些改进，而希望将它们作为VS Code工作台的核心概念。

一旦我们开始在团队中进行UX讨论，我们也希望社区参与进来，然后我们还将讨论我们在当前设计中看到的缺陷以及我们计划改进的地方。

bpasero 于 2016-03-13

@bpasero非常感谢，这就是我想知道的全部。 :)

eyalsk 于 2016-03-13

@bpasero太棒了。我知道你们正在为产品付出巨大的努力，我们都非常感谢。我认为我们很多人都会因为UI中缺少选项卡而感到沮丧，因为我们严重依赖它们，而完全改变工作方式并不是一种选择。我们希望它是目前最好的编辑器，而且确实接近完成它。

jayrosen1576 于 2016-03-13

在不阅读整个线程的情况下，我为此给出了一个大的：+1:。

我已经使用Sublime多年了，喜欢这些标签。我看到工作文件填补了部分空白，但还不完全。我无法完全解释为什么，但是请给我我的标签！

glennblock 于 2016-03-14

+1

极其必要。

castrojunin 于 2016-03-15

+1

在开发过程中，我处理许多不同的文件类型，因此我经常想在右侧为一种类型的文件创建一个标签组，在左侧为其他类型的文件创建另一个标签组。例如，在使用量角器/ webdriverjs代码时，我喜欢将所有“页面对象”保留在右侧，并将所有“规范”保留在左侧，并分别进行逻辑分组。同样，在处理前端内容时，我将在所有js / ts文件的右侧保留一个选项卡组，在html和css的左侧保留一个选项卡组。

这只是两个例子，但是我几乎每时每刻都在一定程度上做到这一点，并且这种策略在我多年的开发中一直为我服务很好，我发现它非常有用。

虽然Code当然允许我具有多个窗格，但是全局文件列表方法使区分文件类型变得更加困难，因此我发现自己浪费了很多时间来滚动要查看的文件的列表。另外，当我（本能地）尝试关闭右窗格中的一个文件时，整个窗格消失了，这非常令人沮丧，尤其是在使用常规VS超过16年之后，这使我开始期望窗格在其余部分保持打开状态可见文件。

Code中缺少选项卡组非常令人失望，我认为不应强迫或说服人们以某种方式工作，因为您认为“更好”或“没有充分理由使用选项卡”。就在这里。也许您只是没有以最好的方式使用它们，或者觉得它们没有用，但是我们当中有很多人会并且真的很喜欢选项卡组这样的基本功能。

我的理解是，代码基于Atom，而Atom已经具有选项卡组支持。似乎需要很多额外的工作才能删除此功能，这对我来说并没有太大意义。至少允许用户选择所需的体验，以便他们可以以最适合自己的方式使用Code。

请把标签组带回到VS Code。

nub340 于 2016-03-15

也许如果您在“工作文件”列表中的文件名周围绘制框，人们会发现它在功能上等同于左侧选项卡... :-)

ChrisMiami 于 2016-03-17

@ChrisMiami ：除非不是。（如果有的话，我可能会愿意忍受。）

kfranqueiro 于 2016-03-17

大声笑

2016年3月17日，星期四，上午4:59 Kenneth G. Franqueiro <
[email protected]>写道：

@ChrisMiami https://github.com/ChrisMiami ：除非不是
https://github.com/Microsoft/vscode/issues/224#issuecomment -166931316。
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -197603728

glennblock 于 2016-03-17

@kfranqueiro在等待适当的选项卡解决方案时，您可能会对采用我使用的键绑定感兴趣，这使ctrl + w和ctrl + shift + w更加接近常规的选项卡实现。

Tyriar 于 2016-03-17

@ nub340 VSCode不是基于Atom而是基于Electron，它是由与Atom合作的同一小组制作的。

eyalsk 于 2016-03-18

+1请加上！！！

Sokol-ua 于 2016-03-18

我还认为这是本来不错的编辑器所无法提供的功能。

erkmos 于 2016-03-18

请添加标签页作为选项，或者允许第三方插件使用标签页功能。

anthonytietjen 于 2016-03-19

关于VSC（在这个愚蠢的名字之后），令我震惊的第一件事是_not_有选项卡的方式。

我目前有8个文件在打开-标签对我来说毫无意义，因为文件名不会显示在标签上。

我_adore_ CTRL + TAB和“工作文件”列表。

如果必须添加选项卡，请使其成为可选项。

leegee 于 2016-03-21

👎6 👍3

@leegee它们不是“毫无意义的”，您只是不需要它们。您是否认为从事不同类型项目的人可能会有不同的用例？

给数以千计的投票支持标签的人，我认为这里唯一的“毫无意义”的事情就是您的评论:)

jon64digital 于 2016-03-21

👍3 😕1

@ jon64digital ：我看到该项目已征求用户对选项卡前景的一般评论-我认为这意味着我们应该发表自己的看法。现在，我意识到我应该先给您发送电子邮件，以便我表达您的意见，并避免您粗鲁的专项指控。我很抱歉。

leegee 于 2016-03-21

@ jon64digital @leegee表示，对他来说，他们毫无意义，不是一般。我完全支持制表符，但我同意将制表符作为不使用制表符的选项可以关闭。让我们保持讨论的文明性，不要诉诸于人身攻击。没有人有不正确的意见。他们只是...意见。

jayrosen1576 于 2016-03-21

👍2

@ jayrosen1576他编辑了他的评论。如果它最初说“对我来说毫无意义”，那么我当然不会说我做了什么。我还假定其他两个对他的评论投了反对票的人在他编辑之前就这样做了。

我完全同意，每个人都有权发表意见，但是这里似乎有几个人不需要在工作流程中使用选项卡，他们试图通过放置-1或告诉MS该功能拒绝了那些确实想要它们的人。不需要，或将以某种方式从更重要的功能中转移资源。鉴于他们可以看到有多少人想要标签，我觉得这很自私，还有些不成熟。

无论如何，如果有人认为这是人身攻击，我深表歉意。之后我确实放了一个笑脸。

jon64digital 于 2016-03-21

如果有任何想法，我认为本讨论只是说明开发人员可以使用多种方式使用IDE，并且所有这些方式对于他们的用例都是完全有效的。没有一种“正确”的方法，总之，这只是完成工作的一种工具。有些开发人员喜欢使用标签，以便他们可以像文件一样随意分组，而其他开发人员则找到一个完全适合的MRU列表。然后，您便有了那些只使用记事本来完成所有工作的人，而我们全都是三色紫罗兰哈哈。

认真地说，我只是感觉，由于选项卡几乎一直是Visual Studio的重要组成部分，所以有很多开发人员已经习惯了其实用程序，因此使单个MRU列表成为可选的（选择启用或停用）它将使本来就很棒的工具VS Code变得更加通用。

nub340 于 2016-03-21

👍2

@ nub340恰好！我们中的某些人喜欢标签，因为它们一直是我们作为开发人员/用户的经验的一部分，我个人很喜欢在顶部查看我正在处理的文件，与工作文件相比，标签没有内在的优势，但这就是其中的一部分。我们喜欢它。

eyalsk 于 2016-03-22

同意，我希望将其作为一种选择，而不是强制执行。
2016年3月22日星期二，上午6:22 Eyal Solnik [email protected]
写道：

@ nub340 https://github.com/nub340完全一样！我们中有些人喜欢标签，因为
作为开发人员/用户，他们一直是我们经验的一部分，我个人很喜欢
在顶部查看我正在处理的文件，没有固有的
标签相对于工作文件的优势，但这就是我们中的一些人喜欢的方式。
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -199565160

glennblock 于 2016-03-22

我们在Vic-20上没有标签。

讨论得出的一件事是，（制造的）任何东西
可用，它应该是可定制的。

leegee 于 2016-03-22

@glennblock ， @leegee是的，它绝对应该是一个选择，但对于不希望使用这些文件的人，工作文件是否应该获得相同的待遇？但是，最好在另一个功能请求中讨论它。 :)

eyalsk 于 2016-03-22

我已经在此处发布了此文本： https :

对于此讨论也是有效的。我很高兴看到@bpasero的回复。

我想要这个功能。讨论完毕。他妈的您的意见@bpasero我不在乎您认为对与

PeterMtj 于 2016-03-24

👎10 😄3 ❤1

哈哈@PeterMtj ，感谢您说我们都在想:)

@bpasero似乎习惯于否决并抹黑他不会亲自使用并且不适合其个人工作流程的任何功能。

人们之所以使用Microsoft软件，主要是因为他们必须这样做，而很少因为他们喜欢它，而当您看到Microsoft员工具有与他一样的态度时，它就说明了为什么他们不能设计像Sublime Text这样的软件。我已经尽最大努力使用VS Code，但是我将要卸载它。

jon64digital 于 2016-03-24

👎1 👍1

@PeterMtj认真吗？那就是你对待事物的方式？骂人？如果您不尊重他，那么请尊重自己！

@ jon64digital他可以投票或发表他的个人意见，那很好！我们不需要个人化，当然也不必诅咒别人的意见！

我也不同意他的最初反应，我说“不”并不专业，很粗鲁，但我认为，不管人们的意见如何，社区都可以做得更好，保持文明。

人们之所以使用Microsoft软件，主要是因为他们必须这样做，而很少因为他们喜欢它，而当您看到Microsoft员工具有与他一样的态度时，它就说明了为什么他们不能设计像Sublime Text这样的软件。我已经尽最大努力使用VS Code，但是我将要卸载它。

编辑：人们不必使用Microsoft产品！我当然不必这样做，而是说人们很少这样做是因为他们喜欢它，这只是在胡说八道！微软生产了一些出色的产品和技术，我远不是他们所做的一切的忠实拥护者，但他们肯定做对了一些事情！没有人强迫任何人使用VSCode，如果有人强迫您使用VSCode，则应将其开除，因为您需要选择自己的工具！雇主唯一关心的是您的工作而不是工作！

请不要将其转变为火焰战争并保持建设性！

eyalsk 于 2016-03-24

👍2

@eyalsk

我不是要发动火焰战争，也不是在说垃圾，但我100％坚持我的话。从历史上看，MS一直将自己的产品与操作系统绑定在一起，并迫使人们使用他们的软件，因为他们知道自己的产品还不够强大。我知道很多人在工作中必须使用MS Office，因为我别无选择，所以我不得不使用Visual Studio，而且我可以指望用一只手自愿使用Internet Explorer的人数。由于这些做法，它们甚至成为反托拉斯诉讼的主题，因此，说没有人让任何人使用MS软件都是天真的。

事情最近朝着正确的方向发展，并且它们变得与平台无关，并试图使其软件与其他软件更好地互操作。我敢肯定，MS的优秀人才正在尝试开发出色的软件并向人们提供他们想要的东西，但是bpasero显然不是其中之一。他的开明态度对他们不值得赞扬，

这里有一个漫长的话题，数百个人从代码编辑器中准确地告诉MS他们想要什么。这并不是好像他们不知道我们想要什么。然后，我们的一名MS员工在这里说：“不，您基本上都错了”。难道不是描绘了一家与观众不完全吻合的公司吗？

只是我的2c。

jon64digital 于 2016-03-25

@ jon64digital

我不是要发动火焰战争，也不是在说垃圾，但我100％坚持我的话。从历史上看，MS一直将自己的产品与操作系统绑定在一起，并迫使人们使用他们的软件，因为他们知道自己的产品还不够强大。

那只是您的偏见假设，我尊重这一点，但是我们可以说出世界上任何其他公司的完全一样的名字，例如苹果，甲骨文和谷歌。

我知道很多人在工作中必须使用MS Office，

人们并没有被迫使用MS Office，这是雇主的决定，Libre office是一个很好的产品，它是一个很好的选择。

我之前不得不使用Visual Studio，因为我别无选择

我不知道你为什么别无选择，但是今天你绝对有选择！即使人们大量使用Visual Studio进行.NET开发，我也总是有选择的余地。我使用SharpDevelop，Vim和Notepad ++，我从来没有遇到过使用多个编辑器的问题，反正我也不是设计师的忠实拥护者...

对于C / ++，除非使用VC ++，否则您将获得编辑器和IDE的更多支持：)

此外，我从来不明白为什么有些人将自己锁定在X所制造的特定技术堆栈上，除了微软之外，还有许多其他技术。

我可以算出愿意用一只手自愿使用Internet Explorer的人数。

没错，Internet Explorer在版本9之前是非常糟糕的，但是自那时以来，它们已经有了很大的改进，即使我是FireFox用户，我也不会因为他们的过去来判断微软，而是会因为他们的身份来判断他们。现在，看起来不错！

由于这些做法，它们甚至成为反托拉斯诉讼的主题，因此，说没有人让任何人使用MS软件都是天真的。

没有人在让任何人使用任何东西，我对大多数人都不了解，但我离幼稚还很远，我很合理。

如果您的雇主选择使用MS技术，那么您肯定会被强迫，但这并不是微软的错，如果您选择使用MS技术，那么您选择它并抱怨它有点愚蠢，那么就有等效的技术与Microsoft一样好，因此人们当然可以选择。

事情最近朝着正确的方向发展，并且它们变得与平台无关，并试图使其软件与其他软件更好地互操作。我敢肯定，MS的优秀人才正在尝试开发出色的软件，并向人们提供他们想要的东西，

究竟！即使我不认为从设计的角度来看，向人们提供想要的东西也是件好事。 :)

但是bpasero显然不是其中之一。他的开明态度对他们不值得赞扬，

我认为我们不需要根据他们的观点来定义人们，当然不是这些观点，成年后也不会使人们容易受到任何形式的人身攻击，发誓对人发脾气并不令人愉快，应予以劝阻，成年后的行为意味着您可以控制自己的愤怒并发表自己对某人或某物的意见，而不会感到反感。

这里有一个漫长的话题，数百个人从代码编辑器中准确地告诉MS他们想要什么。这并不是好像他们不知道我们想要什么。然后，我们的一名MS员工在这里说：“不，您基本上都错了”。难道不是描绘了一家与观众不完全吻合的公司吗？

这是一个公平的观点和抱怨，我不是在说别的！但是@bpasero已经指出，一旦他们将在UX上工作，他们也会解决这个问题。“ _一旦我们开始在团队中进行UX讨论，我们也希望社区参与进来，然后我们还将讨论在当前设计中看到的缺陷以及我们计划改进的地方。

eyalsk 于 2016-03-25

@eyalsk是的，这正是我的解决方法，我不会收回它。我没有冒犯他一个人。我对此感到不满，并且冒犯了标签以外的其他选项，这令我恼火。那是很大的不同。如果看不到，请三思。

@ jon64digital是正确的@bpasero态度。我不知道该怎么想他。也许他只是想说你错了就摆脱工作，这是没有必要的。无论哪种方式， @ bpasero都不应该以他的态度与社区进行交流。那是我的意见。

尝试认识到Microsoft并没有帮助我们。我们正在通过使用Microsoft的产品并提供反馈来帮助Microsoft，以便他们可以制造出体面的产品。这不应该是关于保护选项卡的讨论，而应该是关于选项卡如何工作的讨论，因此vscode实际上是这样。 Vscode是针对社区的，这就是我们的权利，在极端情况下，如果我们所有人都希望在屏幕中间出现红色恐龙，他们应该在不质疑任何理由的情况下做到这一点。我们都有自己的理由。否则，vscode对社区没有用。我就是这样看的。

PeterMtj 于 2016-03-25

@PeterMtj我想我们必须同意不同意。 :)

eyalsk 于 2016-03-25

我想参与讨论并提供一些其他背景信息。我们将总结一下Code的一个重要里程碑。在过去六个月中，我们的主要重点是对可访问性和本地化的支持。这使我们在UI区域中没有任何周期可以主动处理Tabs反馈。现在，三月计划（＃3555）上的大多数复选框都已选中，我们正慢慢开始再次查找。在4月，我们将加强这个主题。 @bpasero在我们的用户体验的开发中发挥了关键作用，这将是下一个重大发展。

感谢大家的热情和反馈，帮助我们使VS Code成为最好的产品。

egamma 于 2016-03-26

👍1

TIA的辅助功能选项-对我们将产生重大影响
半盲

2016年3月26日星期六，Erich Gamma 01：38， notifications @ github.com写道：

我想参与讨论并提供一些其他背景信息。
我们将总结一下Code的一个重要里程碑。我们的重点
在过去的6个月中，对可访问性和本地化提供了支持。这个
并没有让我们在用户界面区域留下任何周期来积极处理Tabs反馈。
现在，三月计划中的大多数复选框（＃3555
https://github.com/Microsoft/vscode/issues/3555）已选中，我们
慢慢开始再次抬头。在4月，我们将加强这个主题。
@bpasero https://github.com/bpasero在
UX的开发，这将是下一个重大发展。
感谢大家的热情和反馈，帮助我们使VS Code
最好的产品。
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -201618115

leegee 于 2016-03-26

@egamma我真的非常感谢您和您的团队所做的一切，我认为您做得很好！但是我感觉@bpasero的第一反应不满，如果他对为什么他认为制表符不是一个选项而不只是说“不”的见解，可以避免这种情况。

无论如何，让我们着眼于现在，// build /事件之前是否有任何新的构建？：D

eyalsk 于 2016-03-26

@eyalsk我相信“否”注释实际上是指@inakianduaga的第一个答复，因为不可能使用当前的扩展API来实现选项卡。我认为这是误解，因为它说“制表符”将永远不会发生，但是，如果真是这样，这个问题很可能已经解决。

Tyriar 于 2016-03-26

@Tyriar ，谢谢！ :)

eyalsk 于 2016-03-26

无论如何，让我们着眼于现在，// build /事件之前是否有任何新的构建？：D

在内部通道（发行说明）上，新版本的比特已经在等您，请使用它并提供反馈。

egamma 于 2016-03-26

@egamma谢谢！ ;）

eyalsk 于 2016-03-26

我们正在根据这种经验开始设计工作，并希望尽可能多地使社区参与。随着我们不断取得您的反馈意见，我将进行定期的设计讨论。大多数情况下，这些活动将是一对一的会议，在此我们分享我们的工作成果并与您讨论。

第一届会议将于本周三举行。如果您有兴趣，请在这里注册： https :

stevencl 于 2016-04-04

👍7

太棒了！
于2016年4月4日星期一上午3:54史蒂文·克拉克[email protected]
写道：

我们正在根据这种经验开始设计工作，并希望
尽我们最大的努力让社区参与进来。我将进行常规设计
我们不断取得进展以获取您的反馈。通常这些会
一对一会议，我们分享我们正在研究的内容并进行讨论
他们和你在一起。
第一届会议将于本周三举行。请在这里注册
你感兴趣：
https://calendly.com/stevencl/visual-studio-code-tabs-design-discussion/04-06-2016
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -205239769

glennblock 于 2016-04-04

期待听到您对新设计的反馈，我们正在探索与此问题相关的信息。如果您有兴趣，请通过上面@stevencl的评论上的链接进行

bgashler1 于 2016-04-04

仅凌晨3点和凌晨4点？没有其他时间了吗？我无法在周三上午3/4（太平洋标准时间）达到标准时间。

2016年4月4日星期一8:14 AM Brad Gashler [email protected]
写道：

期待听到您对我们正在探索的新设计的反馈
与这个问题有关。如果您有兴趣，请通过以下链接进行注册
史蒂文的评论在上面！
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

glennblock 于 2016-04-04

如果您有根据PST安排的时间，那很好，很多人（包括我）都可以参加

{移动}

2016年4月4日，星期一，上午7:50，“ Glenn Block” [email protected]写道：

仅凌晨3点和凌晨4点？没有其他时间了吗？我无法在周三上午3/4（太平洋标准时间）达到标准时间。

2016年4月4日星期一8:14 AM Brad Gashler [email protected]

写道：

期待听到您对我们正在探索的新设计的反馈
与这个问题有关。如果您有兴趣，请通过以下链接进行注册
史蒂文的评论在上面！
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -205342923

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件或在GitHub上查看

shivateja-madipalli 于 2016-04-04

是的，请。我想参加这次对话。

glennblock 于 2016-04-04

抱歉，我知道这些时间并不适合所有人。将来，当我们计划定期举行会议时，我们将研究在不同时区安排会议的方式。

stevencl 于 2016-04-04

为什么不只在本周的另一个时间安排另一个呢？这是一个
有趣的热门话题。

2016年4月4日星期一上午9:44史蒂文·克拉克[email protected]
写道：

抱歉，我知道这些时间并不适合所有人。将来我们
我们将研究在不同时区安排会议的方式
计划定期举行。
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -205386984

glennblock 于 2016-04-04

就是这样，您所看到的时隙就是仍然可用的时隙。我当天晚些时候有空位，但是很快就被占用了。

就像我说的，我们将来会尝试安排在不同时区的会议。

感谢您的关注。

stevencl 于 2016-04-04

我知道了，我猜他们很快就装满了（很好）
2016年4月4日星期一上午11:30史蒂文·克拉克[email protected]
写道：

就是这样，您所看到的时隙就是
仍然可用。我当天晚些时候有空位，但这些空位已被占用
太快了。
就像我说的，我们将尝试安排在不同时区的会议
未来。
感谢您的关注。
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

glennblock 于 2016-04-04

您可以/可以录制会话吗？

在2016年4月4日星期一上午11:32 Glenn Block glenn。 [email protected]写道：

我知道了，我猜他们很快就装满了（很好）
2016年4月4日星期一上午11:30史蒂文·克拉克[email protected]
写道：
就是这样，您所看到的时隙就是
仍然可用。我当天晚些时候有空位，但这些空位已被占用
太快了。
就像我说的，我们将尝试安排在不同时区的会议
未来。
感谢您的关注。
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -205436942

glennblock 于 2016-04-04

希望我能早点看到这个，所以我可以报名参加。对于它的价值，我希望您不要实现制表符。我已经从vim升级到TextMate，再到Sublime升级到Atom，现在又升级到VS Code（一路上有很多IDE），因此我在使用制表符方面有很多经验。对我来说，它们是人们使用的拐杖，永远不会过去。在一个大型项目上管理许多打开的选项卡是一种令人沮丧的练习，它增加了我不需要的其他杂务。忘记关闭一些，它很快就变得毫无希望。对于你们中那些从来没有遇到这种纪律的人来说，荣誉。但是，为什么要花精力进行不必要的工作呢？

更重要的是，我认为制表符使人们从FILES角度进行思考，而对于大多数代码开发而言，制表符应将重点放在函数，类，名称空间-符号上。文件是大多数情况下的实现细节，不应主导您的导航。我认为VS Code确实有机会提供新的更好的东西。

我意识到这只是我的偏爱，并且我理解为什么很多人要求选项卡是可选的。这似乎是一个合理的折衷方案，但是很难很好地支持两个不同的导航工作流程。只需尝试关闭Atom中的tabs插件，看看有多少东西不起作用或效果不佳，因为开发人员希望可以使用tabs。因此，出于我自私的原因，我希望VS Code开发人员专注于不是基于选项卡（甚至文件）的导航。

indiejames 于 2016-04-05

👎4 👍3

同上@indiejames

WhatsThatItsPat 于 2016-04-05

如果您实施标签，请为多个文件支持多行。我讨厌标签栏上有一个滚动条。我最喜欢的Tabs实现是Tabs Studio 。另请参阅如何将具有相同基本名称的文件自动分组在一起。

ghost 于 2016-04-05

在Sublime中工作时，我会根据需要打开选项卡。我不会打开大量标签，而是经常使用“全部关闭”将内容重新整理。

我从事多个IDE和文本编辑器的开发已有30多年的历史。我不认为制表符是拐杖，它是有用的组织工具。是的，如果您拥有数不胜数的标签页，他们可能会失控，但我没有...。

就倾向于关注文件等的选项卡而言，代码位于文件中，并且文件用于组织，而VS代码围绕管理文件夹和代码文件而构建。

我完全得到一些可能更喜欢没有选项卡的信息，我并不是说要摆脱那里的内容，但是拥有受支持的选项卡工作流程会很好。
2016年4月5日星期二，7：32 AM error [email protected]写道：

如果您实施标签，请为多个文件支持多行。我恨
标签栏上有一个滚动条。我最喜欢的标签实现是标签
Studio https://tabsstudio.com/。
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -205834354

glennblock 于 2016-04-05

👍2

“它使用户更容易滥用产品”是不支持该功能的可怕原因。该工具可以简化工作流程，而不是强制工作流程。如果用户找不到合适的工作流程，则该用户更有可能选择其他可以使用的工具，而不是适应陌生的范例。

我目前正在处理一些密切相关的文件，它们之间来回跳转。每次需要切换时，都需要从侧边栏或下拉菜单中进行选择，下拉菜单的时间是标签页的3-4倍。

ghost 于 2016-04-05

@indiejames

但是很难很好地支持两个不同的导航工作流程。只需尝试打开Atom中的tabs插件，看看由于开发人员希望使用tabs，事情可能会不起作用或效果不佳。因此，出于我自私的原因，我希望VS Code开发人员专注于不是基于选项卡（甚至文件）的导航。

支持两个不同的导航工作流程或两个以上的导航工作流程并不是很困难，正确地设计才是真正困难的！

如果您确实要支持选项卡和工作文件或其他工作流程，则需要向后退几步，进行缩小并重新设计导航，使工作流程成为人们可以选择的策略。

创建扩展名只是为了在编辑器中具有选项卡而不考虑用例以及人们如何使用选项卡或其他工作流，只是缺少了没有真正好处的原因，因此很可能是失败。

代码导航和文件导航之间是有区别的，当您编码时，您肯定需要
考虑符号而不是文件，但是代码存在于文件中，有时您也需要处理它，例如，我没有打开很多标签，但是当我在多个项目中工作时，通常每个打开的项目都有一个相关的文件，大量使用热键，但由于选项卡始终位于顶部，而当我查看编辑器时，它们始终位于此处，这可能是心理上的，但这只是帮助我集中精力。

您使用Tab的经历很不幸，我一点也不低估您的经历，我不知道您的工作方式，但我们中的许多人都喜欢它并成功使用。

我认为一种经验不会比另一种更好，但是拥有不同的经验甚至混合经验可能会有所帮助，编辑应该尊重我的经验，不要与之抗衡。

eyalsk 于 2016-04-05

👍2

对于由于其他承诺而无法召开会议的我们来说，这将是非常有帮助的，以便能够提供反馈。
也许，一旦会议在第一天结束，就发布一个会议视频（在所有参与者的允许下），其他人可以在会议剩余时间内查看和评论该视频吗？

显然，这不会很长一段时间，但是希望添加一些不同的观点也不会损害更多反馈。

我真的希望一些Python开发人员和c / c ++开发人员能够参加会议，因为他们的工作流程与JavaScript开发人员的工作流程不同

mikewl 于 2016-04-06

感谢史蒂文（Steven）花时间与我交谈！
与社区的互动确实令人鼓舞，我很享受
跟随vscode开发！

2016年4月6日19:41，Michael Wallace Louwrens < [email protected]

写道：
对于由于其他原因而无法开会的人来说，这将是非常有帮助的
能够提供反馈的承诺。
也许，一旦会议在第一天结束，就发布一个视频
会议（在所有参与者的许可下），其他人可以查看和评论
在剩余的会议时间内进行？
显然，这不会很长一段时间，但更多的反馈也不会
希望添加一些不同的观点。
我真的希望一些Python开发人员和c / c ++开发人员能够参加会议
他们的工作流程与JavaScript开发人员的工作流程不同
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -206261939

TurkeyMan 于 2016-04-06

感谢@TurkeyMan ，今天早些时候与您聊天

对于所有其他无法参加的人，我们将定期进行这些活动，以便以后有机会参加。

我们本周进行的对话都是1：1对话，在此期间我们讨论每个人遇到的问题的详细信息。这使我们对需要解决的问题有更深入的了解。

在接下来的几周中，我们将回顾设计模型时，我们将寻找进行小组讨论和1：1讨论的方法。之后，我们还将研究如何记录和发布会议视频。

stevencl 于 2016-04-06

@stevencl可以为我们无法参加但仍然有兴趣提供反馈的人们发布会议摘要（甚至更好的是录音）。

pesho 于 2016-04-06

👍1

+1
2016年4月6日星期三，上午7:36彼得·彼得罗夫[email protected]
写道：

@stevencl https://github.com/stevencl是否可以发布摘要
我们中那些无力的会议（甚至更好的是录音）
参与，但仍然有兴趣提供反馈。
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -206405009

glennblock 于 2016-04-06

我希望满足我在代码编辑器中对文件导航的期望。我已经尝试了几周的时间来习惯于VScode，并继续回到Sublime。这是我期望的：

无鼠标导航
在打开的文件集中前后导航的能力
轻松关闭文件

到目前为止，不幸的是我发现VScode在这三个方面均对我失败。工作区是不直观的，因为当我关闭文件时，它并没有真正关闭，只是不再可编辑。关闭文件是从我正在使用的文件集中删除该文件的一种心理活动。

在VScode中，当我在脑海中打开的文件中导航时，我总是遇到我认为以前被丢弃的“垃圾”。这非常令人分心，我最终在工作区中打开了20个ish文件，最终无法再跟踪它并仅关闭它们。

我无法使用键盘在打开的文件之间快速切换，即在我的头上形成了一个链表。我打开它们的顺序与我打开它们的顺序一样重要。我发现Ctrl + Tab没用，因为我必须在列表中一一读取文件名，然后找出要选择哪个文件名。我可以更快地将5-8个打开的文件翻到正确的位置，方法是简单地识别闪烁的内容，或者只知道所需文件在“列表”中的位置。

我希望这是有道理的。我尝试尽可能优化我的工作流程，使用键盘并避免使用鼠标，因为这会极大地减慢一切。与以前在任何其他编辑器（textmate，vim，sublime，flash，eclipse等）中相比，我在VScode中为此付出的努力更多

alexgorbatchev 于 2016-04-06

👍5

仅重申一下，本周发生的会议记录将不可用，因为每次会议都是1：1对话，每个人讨论他们的工作方式细节以及VS Code遇到的特定问题。在这些对话中，我们不会对任何设计进行详细介绍。

在接下来的几周中，我们将寻找机会进行记录并召开会议，在会议上讨论在VS Code中改进文档管理的设计。在下周的某个时候寻找我的另一个邀请，参加下一轮设计讨论。

感谢您的所有反馈，以及有关VS Code如何为您工作或不工作的详细信息。

stevencl 于 2016-04-06

❤1

只是因为似乎没有人提到过它，而且我怀疑我并不孤单：对我而言，编辑器中的选项卡仅涉及空间内存-即我在哪里，我周围的东西在哪里？

我们生活在现实世界中。我们已经进化为对周围空间的理解和直觉，而我们却没有思考就做到了。这就是为什么我们不用看键盘就可以打字的原因-我们“只知道”按键在哪里并且可以快速打字。使用选项卡，我们出生时使用的默认问题湿软件可以启动，并且我们知道文件在屏幕上的“位置”，并且无需思考，因为我们每天都会使用它的本能，因此可以在文件上进行细化处理。我可以通过编辑器中的选项卡“放下文件”，并且可以记住“我放下文件的地方”，就像我记得下次需要更改频道时放下电视遥控器的位置一样（假设我再有电视了）

对我来说，按时间排序的文件历史记录与这种对空间的直观理解完全相反。如果我知道“ main.java”或键盘上的T键在某个位置，除非我有意并故意移动它，否则我不希望它移动。如果它自己移动，我需要停下来思考并找到它。想象一下一个带轮子的电视遥控器，它可以自己在房子里四处移动，或者是一个键盘，它根据您最近使用每个字母的方式重新排列了按键！太混乱了！ :-)

我真的很喜欢VSCode，但是由于缺少选项卡，我个人感到沮丧和放慢。保持良好的工作状态-我期待看到您的想法！

matt1 于 2016-04-08

👍5 ❤3

@ matt1
您所描述的正是制表符如此有限的原因（对我而言）。选项卡是对放置在物理文件柜中文件上的物理选项卡的隐喻，并且具有所有相同的限制。我宁愿拥有一个自动化的文件柜，在其中我可以键入一些键并跳转到我的信息，而不是一个物理的文件柜，在这里我必须自己对事物进行排序并管理可见标签的有限空间。

我很好奇-您是使用鼠标/触控板还是在其他编辑器上使用组合键来浏览选项卡？
如果仅使用键盘快捷键，则可能有一些我不知道的标签工作流程
我很乐意看到它。但是，我怀疑很多人使用鼠标/触控板-并未意识到上下文切换的效率如何，以及放开它们的手的速度有多慢。它易于学习且易于理解，但功能/生产力低于使用组合键。如果您发现自己用鼠标“触手可及”，这可能很直观，并且可以利用您的空间感，但是这会使您减速。在物理运动上所花费的时间并没有太多，而是在上下文切换本身上。

我意识到这些只是我的意见，大多数人都不同意，但这是Visual Studio _Code_。对于编码人员/开发人员。而且，开发人员很久以前就意识到，对于大多数（不是全部）东西，shell> gui以及桌面隐喻虽然易于学习，但却相当局限。

因此，你们中有些人说“我不能没有标签就无法生存”，是否有可能没有其他工作流程？如果是这样，那么如果收益会提高您的生产率，是否值得尝试？

对于那些尝试在没有标签的情况下工作，无法适应或坦率地说使用标签使您提高工作效率的人来说，我可以接受，这只是诚实的分歧。但是对于那些主张用物理隐喻的人来说，是因为“他们已经工作了30年！” 我会问我们真的需要_another_ TextMate / Sublime / Atom吗？我们不应该尝试移动信封吗？

我毫不怀疑我在这里只是少数（但这并没有使我错），所以这是我要发表的最后一条评论。随意堆积:)

indiejames 于 2016-04-08

👍1

决定签出VS Code，以查看它是否可以免费替代Sublime，但如果没有选项卡式文档，那就不是入门。能够在单实例中设置VS Code，打开多个文档并在它们之间轻松切换是任何文本编辑器的基本要求。保持资源管理器处于打开状态是一种变通方法，但是在VS，浏览器，Sublime等中，使用左选项卡而不是顶部选项卡并不是不自然的。Ctrl-Tab有几个问题，一个是必须看着键盘并移动一只手（除了鼠标以外的其他东西），这是非直觉的。任何暗示没有标签的编辑器的建议，都不只是BloatedNotepad所做的，它显然从未对多个文档进行过任何认真的编辑，例如，调试器逐步浏览包含多个文件作为编译器输入的内容时，这是必需的。

jmeyerzc 于 2016-04-08

@indiejames
标签页对我来说不是生产力。它关于认知。

我个人从来没有发现原始打字速度一直是我工作效率的限制因素。编程需要思考和考虑-考虑到我们花了多少时间思考，对于我来说，单击几下并不是什么大问题。

matt1 于 2016-04-08

@indiejames我使用ctrl +（shift +）tab在众多标签之间导航，而不一定是鼠标。我对工作文件最大的困扰之一就是与-ctrl + tab按最近使用的顺序运行。我不一定记得上次和倒数第二次查看的文件，但对我来说很容易查看/记住我打开/排列文件的顺序。Sublime Text还默认将ctrl +（shift +）tab设置为MRU订购; 我总是更改它，因为它具有用于MRU和可见顺序的命令。

我记得当时有一些Web浏览器（是否可能是Opera的预闪烁功能？）默认情况下也将MRU用于ctrl + tab，大概是因为操作系统是针对应用程序的，所以浏览器也可能这样做。我发现它实在是太不直观了，并且不得不格外注意找到我真正想要切换回去的东西……，猜猜是什么，使过程变得缓慢了。

在带有选项卡的Sublime Text中，仅使用快速打开的参数也与在带有工作文件的VS Code中一样有效。选项卡根本不禁止该工作流程。

kfranqueiro 于 2016-04-08

对于那些更喜欢VS Code中当前工作文件方法的人，实际上有多少人更喜欢单击工作文件列表中的文件，而不是以下工作流程？

使用Ctrl + E / ⌘ + E快速打开最近的文件。
使用Ctrl + Tab切换最近的文件

bgashler1 于 2016-04-08

顺便说一下，对于那些喜欢标签的人，您的反馈意见非常有用，因为我们正在研究将其添加到产品中。非常感谢您继续分享！

bgashler1 于 2016-04-08

@ bgashler1
我更喜欢键盘快捷键。并非如此，我可以成为最快的打字员，但是因为我发现他们的注意力分散程度较小，所以可以移动鼠标/触控板。

indiejames 于 2016-04-08

我认为许多“正在使用的文件且永远没有选项卡”的人群所缺少的是他们当中很多人使用选项卡的方式。例如，当我在MVC应用程序（Web，移动或桌面）上工作时，我倾向于按特定顺序在一个或多个垂直窗格（也需要VSCode）中具有选项卡：模型文件，视图文件，控制器文件。因此，我经常打开的设置如下所示：

左窗格

模型1文件（标签）| 查看1个文件（标签）| 控制器1文件（选项卡）

右窗格

模型2文件（标签）| 查看2个文件（标签）| 控制器2文件（选项卡）

通过此设置，当我戴上UI / UX帽子时，可以为正在比较的两个组件或查看文件快速选择模型文件。使用工作文件绝对不能有效地完成此任务，尤其是在您还打开了其他文件（例如CSS，db脚本等）的情况下。我做了大量的UI / UX，这是迄今为止的一种普遍做法。我是Java后端开发人员还是DBA，那么不，这不是必需的。但是，对于我们绝大多数的全栈Web和移动开发人员来说，没有选项卡（和选项卡式垂直/水平窗格）是一个极端的障碍。在短期内使用VSCode时，由于缺少此功能，我对此持有严重保留。没有人能说服标签页没有用，工作文件列表也不是一项创新（Adobe Brackets也提供工作文件列表，并且自2012年以来一直存在）。

同样，这不是一个全有或全无的问题。我们只是简单地要求其他编辑器中存在相同的功能，即使该功能默认情况下处于关闭状态。如果VSCode完全像Atom一样实现选项卡/窗口窗格，它将解决99.99％的与选项卡相关的抓取。我知道要实现它并不是一件容易的事，但是我想我们中的许多人会满意地等待更长的时间（几个月而不是几年），以便正确完成此功能，而不是将其保留在积压的工作中。

只是我的2美分...

jayrosen1576 于 2016-04-08

👍3

虽然我已经将大部分信息传达给@ bgashler1了，但我将在此处做一些说明来为我解释理想的行为。

按键绑定应关闭工作文件，将其从工作文件列表和MRU（最近使用）堆栈中删除。我具有以下按键来完成此操作：

json { "key": "ctrl+shift+w", "command": "workbench.files.action.closeAllFiles" }, { "key": "ctrl+w", "command": "workbench.files.action.closeFile" },

编辑器中的文件应“堆叠”，这样，当您关闭一个文件时，将显示MRU堆栈中的最后一个文件。
ctrl + shift + t应该恢复最近关闭的标签页。此键绑定与vscode中的workbench.action.tasks.test冲突，但这在选项卡式环境中是非常标准的热键。我在这里为命令创建了功能请求https://github.com/Microsoft/vscode/issues/3989
Ctrl + Tab和Ctrl + Shift + Tab只能在“工作文件”列表中的文件中旋转，而不能在“已预览”的文件中旋转（在资源管理器中单击，然后导航）。
我希望将工作文件放在编辑器顶部。原因如下：
- 无论我打开了哪个侧边栏，我都希望能够直观地看到我的工作文件。相关： https :
- 在过去的20年中，我一直在进行编程，一直在编辑器上方查找我的工作文件。很难改掉。

Tyriar 于 2016-04-08

👍11 ❤2 👎2

@bpasero

顺便说一下，对于那些喜欢标签的人，您的反馈非常有用，因为我们正在调查将其添加到产品中。非常感谢您继续分享！

我在VSCode中经常使用Ctrl + Tab ，但是我认为Visual Studio的体验要好得多，因为除了文件之外，我还可以导航到UI的其他部分，我可以使用它导航到Package Console Manager，解决方案资源管理器等...

@Tyriar好点子！

eyalsk 于 2016-04-08

[哲学警告！]

为什么ctrl+tab比“工作文件”概念有用得多？这是症结所在。我个人认为有两个问题在起作用。

首先， ctrl+tab是键盘快捷键，键盘快捷键与下划线标记是潜意识相关联的-用户期望ctrl+tab会在当前编辑器中更改文件，该标记当前放置在当前编辑器中，即正是它的作用。这与不与特定编辑器关联的“工作文件”或导航器不同-它们与除一个编辑器之外的所有编辑器都水平隔开，并且与_mostcent_编辑器关联-通常与鼠标一起使用。即使将它们与键盘一起使用，在选择文件时，您也已脱离插入符号。

其次， ctrl+tab以相反的时间顺序向您显示所有您最近看到的文件。 “工作文件”仅显示您双击或对其进行更改的文件，并且以您打扰它们的顺序显示。标准和顺序是任意的，与程序员的思维方式无关-在调用者和函数，类和使用者之间来回跳转。

（意见。里程可能会有所不同。）

编辑：我的意思是：理解为什么一项功能有效而一项功能无效将有助于修复该功能或设计更好的功能。就目前而言，工作文件则没有。

stephenmartindale 于 2016-04-09

👍1

@Tyriar ：我个人非常讨厌单击文件不会显示在工作文件中的事实。我想要我最近使用的堆栈中看到的所有文件-甚至是只读的外部文件。我打开它们是有原因的。如果我处理完了它们，它们将很快从列表中消失。充其量，应该有一个选项可以使单击和双击的行为相同。

stephenmartindale 于 2016-04-09

👍1

在此问题的背景下，我想出了如何从崇高中得到大部分东西的方法：

[
  { "key": "cmd+w", "command": "workbench.files.action.closeFile" },
  { "key": "cmd+shift+]", "command": "workbench.files.action.openNextWorkingFile" },
  { "key": "cmd+shift+[", "command": "workbench.files.action.openPreviousWorkingFile" }
]

alexgorbatchev 于 2016-04-09

@stephenmartindale我不确定是否有人进行过功能请求以禁用“预览文件”。

Tyriar 于 2016-04-09

@stephenmartindale我们正在寻找一种方法来固定“预览文件”以使其保持打开状态，包括只读文件。

我们希望保留“预览文件”，因为很多时候，人们在打开多个文件之前都不知道他们要查找的文件（这可能会导致不希望有的打开文件数量不相关）。

bgashler1 于 2016-04-09

我真的很喜欢Sublime的流程。单击即可跳转到该文件，
双击它保持打开状态。
2016年4月9日，星期六，上午11:49 Brad Gashler [email protected]
写道：

我们正在寻找@stephenmartindale https://github.com/stephenmartindale
锁定“预览文件”以保持打开的方式。
我们想保留“预览文件”，因为很多时候人们不知道
在打开多个文件之前，他们正在寻找什么文件（可以
导致打开文件混乱的数量不理想）。
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -207830702

glennblock 于 2016-04-09

👍4

@Tyriar，@ bgashler1，@stevencl我认为这是更好地对标签和工作文件的两个新职位，以收集反馈。

只是我的意见，但我觉得这比在这里讨论这两个功能要好得多，这个功能足够长。 :)

eyalsk 于 2016-04-09

👎请不要这样做，或者至少使其成为可选项。简洁的无标签UI是我最喜欢的VS代码之一。

tobico 于 2016-04-12

👎12

@tobico不一定是全部或全部...据我所知，我希望工作文件和选项卡都是可选的，但对于希望拥有这种经验的人来说却是不可或缺的。

eyalsk 于 2016-04-12

👍1

我想说一下，Ctrl + W不仅应该关闭当前编辑器，而且应该关闭相应的打开的工作文件。对我来说，这是当前实现中最大的缺点。 Ctrl + Tab会列出所有最近的文件，而不仅仅是工作文件中的文件。再次考虑，第三个警告是单击不会将文件作为工作文件打开，而对其进行编辑会打开。

csholmq 于 2016-04-12

👍2

+1

skuzmin 于 2016-04-12

👎2

@csholmq，您现在可以执行此操作，请参阅https://github.com/Microsoft/vscode/issues/224#issuecomment -207507479中的自定义按键绑定

Tyriar 于 2016-04-12

@Tyriar这几乎解决了我所有的警告。谢谢！

csholmq 于 2016-04-13

👍1

在3分钟内，我停止使用VS Code，然后回到Atom。没有标签，没有去。抱歉，我的工作流程已经深入到我。我敢打赌，四年前的快速民意测验会更快地获得您的UI答案。但是，微软的傲慢态度也要解决未损坏的问题。

zunama 于 2016-04-14

👍7

@zunama我们没有忘记想要标签和改进文档管理的用户。现在我们是1.0，这是解决这些问题的最高优先事项之一。很棒的事情即将出现在VS Code中。

bgashler1 于 2016-04-14

👍12 🎉7 ❤5

作为Web开发人员，制表符对我很重要。与台式机程序员（当时主要专注于单个文件）不同，我们总是在窗口之间切换并同时使用Mouse（例如，从Photoshop切片图像，然后立即返回编辑器，或者在浏览器中进行调试，然后转到返回另一个文件进行修复）。使用标签，我们可以快速导航到目标文件。使用快捷方式，还有2个步骤。使用侧栏“工作文件”，可以减少主代码区域中的空间（因为我们将Photoshop＆Editor或浏览器并排放置）。编辑器中的Height较少。您总能记住几行，不是吗？

另外，“最高级标签”更适合人眼。您可以同时扫描顶部的标签标题和主要区号。但是您不能一起读取左working files和主代码。自己尝试。此外，标签页更宽，更适合鼠标移动。（即使您不关注它，也可以预测）

KayLeung 于 2016-04-15

👍5

+1/0

chai2010 于 2016-04-15

👎6

+1

SergeiSc 于 2016-04-15

👎5

只是我个人的意见，但请不要再做-1，+ 1了……我的意思是，除了建议您喜欢或不喜欢此功能外，可以使用反应/表情符号的内容并不能说明您的经历，因此如果您已经写过帖子，请确保它有用！我敢肯定，您对事物以及对它们的工作方式拥有自己的防腐剂！否则，只需使用表情符号即可。

eyalsk 于 2016-04-15

🎉1 👍1

元：
@eyalsk在这种情况下，讨论仍在进行中，因此确实显得多余。但是，对于您希望引起关注的问题，“添加您的反应”真的等效吗？难道不是仅警告评论操作，而不是表明问题是热门话题？也就是说，它会警告标记有问题的开发人员还是将问题设置为已修改？

csholmq 于 2016-04-15

@csholmq我不知道我是否正确理解了您，但我指的不是反应/表情，而是其中只包含+ 1，-1的帖子，它没有任何价值，更有意义的输入可以而不是写带有+ 1，-1的帖子...仅是我的看法，我将在我的帖子中对此进行修改和强调。

eyalsk 于 2016-04-15

@zunama尝试寻找更好的选择并不是傲慢自大。 “不破”不是反对寻找新东西的有效论据。这几乎是一个争论（也许还有更好的东西吗？）。尽管我在这次讨论中注意到，如果VS Code今天想得到充分使用

返回您的评论：如果您想做正确的事情，则无需花费3分钟就退出。您列举了对有用评论的观点，并寻求可能的改进。 3分钟的视点对您的设计没有用，而且很危险，因为它有偏见。

您想进行创新时，民意调查无法正常进行。例：

以下哪种nagivation风格对您来说最有效？

有事（尝试一些可能更好的新方法）
标签。（您学会了爱的良好旧工作方式）。

当然选项卡会赢。但是，可能其他想法可以为新的标准导航UI铺平道路。

Measurity 于 2016-04-15

老实说，对我而言，VS Code的定义功能之一是没有制表符。一开始我什至没有意识到他们不见了！这是一个非常有趣的观点。

每当我使用制表符时，它们总是变得混乱不堪，无法找到。当我无法在选项卡列表中立即看到某个文件时，我的第一反应是重新打开该文件。。。然后我发现它已经打开了。当然，在此过程中，选项卡的顺序会严重混乱。这就是我在Visual Studio 2015中发生的情况。

在一切都一样的世界中，拥有一种身份令人耳目一新。

PS。但是，我对“工作文件”部分印象不深。我主要使用它来快速查看哪些文件需要保存。

PSS。一个想法-如果某天在vs代码中包含标签，那么最好限制打开的标签的最大数量，即在打开新标签时自动关闭最旧的标签？

RussBaz 于 2016-04-15

@RussBaz我不认为限制选项卡的数量不是一个好主意，因为该数量可以因用户而

tabs.autoClose =“不可见”，“关闭”，“时间”，x，其中x是数字

eyalsk 于 2016-04-16

这是一个奇怪的想法。如果我喜欢16个标签，而您喜欢4个，那么很简单。您使用4个标签，而我将使用16个标签！为什么说自己的方法比我的方法好，反之亦然。这到底是什么？只要选项卡在“选项” /“首选项”中被激活/停用，就连关于选项卡的对话也是毫无意义的。那些不需要标签的人，太好了！那些想要他们的人，请选中小复选框！确实，不必一定是您的方法比我的方法更好，或者我的知识比您更好。
+1
;）

riclf 于 2016-04-16

👍1

用例示例：我目前在原子中不断地在6个选项卡之间切换。

当我需要进行更深层次的工作时，该数字将增加到大约10。我全部用完了！因此，关闭并重新打开将很痛苦。我可以在其中放置大量文件，但是处理起来要痛苦得多，如果我将模块的每个部分都包含在一个文件中，那么它将膨胀到文件中的6k行。

mikewl 于 2016-04-16

👍1

@测量我同意和不同意你。有些事情需要创新，但首先要问的是，通过删除选项卡，我们可以使工作流程变得更好吗？对我来说，我用于开发的每个编辑器都有一个选项卡界面，因为开发人员通常一次只能处理5-10个文件，而不会记住文件的确切名称或打开文件的顺序。我不得不问，这个新界面如何使它变得更好？如何创新？首先问他们如何使用它，然后问我如何使它变得更好。

至于三分钟的问题，我将假定代码与Sublime（我的首选）或Atom（我正在尝试的东西）没有太大不同，但是如果从一开始就很努力地使用它或展示某人高效地执行文件之间的工作以使某些文件正常工作，然后我将使用对自己的需求更有效的文件，并在准备就绪时研究Code的几个版本。这不是“过时的”思维定式，而是我工作的效率。

zunama 于 2016-04-16

让我们这些更喜欢使用制表符的人切换为不使用制表符，这和
让那些不喜欢使用标签的人切换到标签。我们俩都不想
切换到另一种方法。

我们现在可以停止使用“ Mac vs Windows”，“ Android vs IPhone”类型的
关于哪种方法更好的争论：“制表符与无制表符”？他们俩都很好
不同的人有自己的偏好。

我认为最好的解决方案是将标签添加为可以
可选启用。然后，这两个人群都很高兴。

是否有人反对同时使用这两种方法作为选项，或者
取决于您的喜好？

我认为可以归结为以下两个选择：

1）添加标签作为首选项。为那些喜欢它的人开启，为那些喜欢的人关闭
别。

2）即使我可以选择关闭标签，也不要添加标签。

如果您有选择权，为什么还要投票给选项2
掉？
2016年4月15日，下午7:32，“ James McLaughlin” [email protected]
写道：

@Measuring https://github.com/Measuring我同意和不同意你的看法。
有些事情需要创新，但首先要问的是，
有关工作流程的信息，我们可以通过删除标签来改善。对我来说，每个
我用于开发的单个编辑器具有选项卡界面，因为它是
开发人员一次可以在5-10个文件之间工作而无需
记住文件的确切名称或打开它们的顺序
因此，我不得不问，这个新界面如何使其变得更好？怎么
它创新吗？首先问，他们如何使用它，然后问，我怎么做
更好。至于三分钟的问题，我将假设代码是
与Sublime或Atom并没有太大不同，如果从一开始我就
努力使用它或有效地向某人展示他们需要做什么
在文件之间进行修改，然后我将使用可行的修改
现在可以更好地满足我的需求，并逐步研究Code的几个版本
准备好了。
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545

anthonytietjen 于 2016-04-16

👍5

@ tones411有些人选择选项2只是因为他们认为添加选项卡会以某种方式破坏他们对工作文件的体验。

_我承受不了足够的压力_但是我认为讨论不应该只是添加选项卡并每天调用它，而是要正确设置工作流程，我已经说了很多遍，这意味着，它需要正确的自定义选项，它需要感到整合而不疏远，仍然是可选的！工作文件也是如此。

有些人可能想拥有Vim缓冲区之类的东西，根本不希望既没有选项卡也没有工作文件。

也许像Vim缓冲区之类的东西可以用作VSCode的表面，在这里我们可以使用命令来管理文件，然后在此之上为每个工作流程奠定基础，无论是选项卡，工作文件还是明天的其他东西。

eyalsk 于 2016-04-16

👍3

说得好。这变成了一场宗教辩论。从这里明显
长线，这里有很多人热衷于拥有
标签并相信他们是必需的/有助于他们的工作流程。有
其他不相信制表符是必需的并且它们是障碍的人。

我们只是同意不同意，那很好。只要选项卡是可选的
比那些不想要它们的人不必使用它们。

我个人认为它们很有用，但我不会阻止某人
使用工作文件（如果适用）。它对我不起作用。
2016年4月15日星期五，晚上10:07 tones411 [email protected]写道：

让我们这些更喜欢使用制表符的人切换为不使用制表符，这和
让那些不喜欢使用标签的人切换到标签。我们俩都不想
切换到另一种方法。
我们现在可以停止使用“ Mac vs Windows”，“ Android vs IPhone”类型的
关于哪种方法更好的争论：“制表符与无制表符”？他们俩都很好
不同的人有自己的偏好。
我认为最好的解决方案是将标签添加为可以
可选启用。然后，这两个人群都很高兴。
是否有人反对同时使用这两种方法作为选项，或者
取决于您的喜好？
我认为可以归结为以下两个选择：
1）添加标签作为首选项。为那些喜欢它的人开启，为那些喜欢的人关闭
别。
2）即使我可以选择关闭标签，也不要添加标签。
如果您有选择权，为什么还要投票给选项2
掉？
2016年4月15日，下午7:32，“ James McLaughlin” [email protected]
写道：
@Measuring https://github.com/Measuring我同意和不同意你的看法。
有些事情需要创新，但首先要问的是，
有关工作流程的信息，我们可以通过删除标签来改善。对我来说
每一个
我用于开发的单个编辑器具有选项卡界面，因为它是
开发人员一次可以在5-10个文件之间工作而无需
记住文件的确切名称或打开顺序
他们
因此，我不得不问，这个新界面如何使其变得更好？怎么样
是
它创新吗？首先问，他们如何使用它，然后问，我如何
使
更好。至于三分钟的问题，我将假设
是
与Sublime或Atom并没有太大不同，如果从一开始就正确
一世
努力使用它或有效地向某人展示他们需要做什么
在文件之间使某项工作正常，然后我将使用
作品
现在可以更好地满足我的需求，并逐步研究Code的几个版本
准备好了。
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -210705545
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -210712143

glennblock 于 2016-04-16

👍2

+1

Ephil012 于 2016-04-16

👎1

自从我切换到Code作为主编辑器以来，我一直在跟踪该线程达最后一个月左右，并不断被文件导航行为所困扰。我花了一些时间_trying_来适应“工作文件”部分，无论如何，您都承认这是事后才想到的，还有Ctrl + Tab和Ctrl + P。我对Code非常满意，它很容易成为我最喜欢的编辑器，但是这些文件导航选项的构想很差，一开始就很难理解它们的想法。

其中大多数已被提及，但以下是我的理解：

WF列表实际上是无用的，因为关闭编辑器窗口实际上并不关闭WF中的文件。我实际上需要关闭文件_twice_，并使用鼠标来这样做（Ctrl + W _and_从WF面板中关闭文件）。如果我想让文件保持打开状态，则无需按Ctrl + W-按下Ctrl + W并保持文件“打开”（在WF中可见）有什么意义。是的，可以重新分配，但是我说的是WF的默认行为。

在WF或树状视图中单击文件至少会在一半时间内将文件打开到不需要的编辑器窗口中。如果您有一个带有活动左侧面板的两面板编辑器，则“向侧面打开”将在_right_面板（而不是_new_面板）中打开它，并且在3列的情况下，它将始终在现有面板中打开。这里的问题是“事物不会停留在我放置它们的地方”。我希望告诉我的编辑器我想要的东西在哪里，而不是让我的编辑器根据当前的UI状态决定事物应该在哪里，然后随着UI状态在应用程序其他部分的更改而更改它们。 PITA是_back_到先前打开的文件。

单击和双击文件的行为完全相同，UI完全相同。一次单击即可临时打开文件预览（因为当我不想将其加载到WF中时，因为这将需要两次关闭才能在以后删除），但是会在另一个文件中加载“预览”编辑器（如所提及的当前实现是不可避免的）上方）将文件夹树跳转到新位置，并且加载先前的“预览”文件意味着我必须再次在树视图中导航至该文件夹。由于这种行为，我什至不想承认我花了多少时间连续导航到_exact同一文件夹_ 6次。

我认为，单击文件或双击文件应该具有与_exact相同的行为_，但如果您确实希望单击未在WF / Ctrl + Tab中显示的“预览”，则应该有一个_obvious UI marker_活动的编辑器窗口是预览，替换后将消失。

文件夹树应该_not_跳转到我单击的每个文件的位置，或者在调试时，跳转到库文件夹中的每个文件夹。如果要导航到特定文件夹，则可以导航至该文件夹，一旦完成该操作，我希望它保持这种状态。在选项卡线程中，这似乎无关紧要，但确实如此。

这些绝对荒谬的编辑器面板，WF和文件夹视图行为存在的唯一原因是_因为没有tabs_。如果添加选项卡（如果拆分了编辑器面板，则将其停靠到特定的面板），并且默认情况下是正常的编辑器行为，即总是打开新的tab_中的所有内容，则不需要任何行为。请让我决定如何导航树以及如何堆叠选项卡，并停止尝试向我展示“更好的方式”（除非您实际上有更好的方式-在每天工作大约6个月后，我可以可以肯定地说当前的方法对我来说不是更好）。

当您使用它时，出于对上帝的爱，请让我在多个窗口中查看同一目录中的文件！有一个简单而优雅的解决方案，所有其他基于选项卡的软件都使用了很多年-将选项卡拖到新窗口中-认真的人们，这不是革命性的东西。如果要保持“一个文件夹只能获得一个实例”的行为，则使面板浮动到新窗口中（该窗口仍由主窗口的/附加）。

你们在这个编辑器上做的很棒，我将继续使用它。如果我们可以看到：

标签
禁用WF
停止自动浏览文件夹树
Ripoff选项卡进入浮动编辑器面板（与主界面中的其他编辑器面板具有相同的行为）

然后我认为VS Code将会走得很远。伟大的编辑，我愿意忍受缺点，以利用其余的优势，但是许多其他许多特性仅在等待这几个基本功能。

我很乐意为UI / UX测试或您为用户反馈/输入所做的任何工作提供帮助。让我知道我是否可以为您服务。

谢谢！

anyong 于 2016-04-16

👍11

@anyong感谢您的见解！

对于第3点，不确定是否知道，但是您也可以使用以下方法自定义当前设置：

"explorer.autoReveal": false

我也绑定了workbench.files.action.showActiveFileInExplorer ，因此如果需要，我可以在资源管理器中找到一个随机文件。

Tyriar 于 2016-04-16

@Tyriar我不确定您所指的是哪个版本，但是我在Insider上是最新的，并且该选项尚未执行任何操作。

anyong 于 2016-04-18

：+1：

LauraCrivi 于 2016-04-18

👎3

：+1：

Nesta 于 2016-04-18

👎3

@bpasero我已经阅读了此板上的有关选项卡优缺点的前几条消息。我也了解MSFT团队的立场：该团队团结一致，采用相同的编码风格，对ctrl+tab和/或工作文件部分提出了相同的反映。这是一件好事。通常，所有团队成员的工作流程都是一致的。但是，我们不属于该团队，也不希望发展同样的反应。理想情况下，我们现有的反应应该得到满足，而不是被迫淘汰和替换。编辑器应帮助用户。

我们将不得不适应您对UX的定义，或者停止使用VSCode。有些会适应，有些不会。是关于摆在桌子上的好事与坏事之间的平衡。话虽如此，我认为MSFT团队大大低估了选项卡的重要性，并大大高估了内部开发的反应。

shiretu 于 2016-04-18

👍3

团队和负责人确实需要做出一个简单的决定： VS Code是人机交互实验还是应该是可靠的，可用的IDE _满足开发人员的需求？_如果是前者，那还可以。就我个人而言，我将不再烦恼并转移到其他地方，因为我想完成工作，而不是参与人机交互（HCI）实验，但是我确信他们的实验会带来收益。如果是后者，则至少需要实现制表符，因为这是开发人员想要的，并且如果他们想追逐两只兔子并尝试将人们转换为新的工作流程，则最好是_both_制表符和无制表符。

stephenmartindale 于 2016-04-18

@Tyriar ：我在v.1.0.0-insider中尝试了您的autoReveal设置，它对我也没有任何作用。当我不想要它时，资源管理器仍会跳来跳去-最令人烦恼的是，当我使用“转到定义”并完全打开另一个文件时，它会完全滚动到另一个位置。

这是我在首选项文件中输入的内容： "explorer.autoReveal": false,

stephenmartindale 于 2016-04-18

@anyong @stephenmartindale你是对的，我没有意识到这个设置有多新。它应该在下一个Insiders版本中可用。

Tyriar 于 2016-04-18

说得好@stephenmartindale。没有选项卡，我们所拥有的就是具有自己的Alt-Tab版本的notepad.exe（上面多次提到，该版本已损坏）。我一直在尝试使用“工作文件”，就像它们是侧边选项卡一样，但是一周之后，我已经准备好回到Sublime，这是个问题，尤其是没有办法使侧边栏始终不存在不管应用程序中发生了什么。我以“ Visual Studio ...”这个名字至少期望Visual Studio编辑器的基本功能（选项卡，以及将这些选项卡拖动到自己的窗口中的功能）。他们为何会删除该功能尚无法解释。也许我会在几个月后再检查一下，看看它们是否足够远，可以在构建中放置pre-alpha标记。现在这不过是一个UI实验而已，唯一的问题是它已经失败了，还是濒临失败？

af4jm 于 2016-04-18

正如前面的259条注释中的大多数所指出的那样，我非常希望看到VS Code中的选项卡，类似于它们在Sublime Text中的操作方式。如果不是缺少一项功能，我也很乐意切换。听起来很奇怪，我确实需要能够在同一窗口中至少打开四个文档，以便我可以在它们之间快速切换。

哦，如果Microsoft不希望将VS Code与Sublime Text进行如此多的比较，那么他们不应该设计出外观和行为与之相似的产品。保持选项卡远离GUI并不是阻止与Sublime Text进行比较的方法。这是使这些比较对Microsoft不利的一种方法。

SturmB 于 2016-04-18

@SturmB Sublime不是唯一存在的编辑器，我不认为他们使VSCode成为另一个Sublime模仿者，就像Atom不是Sublime一样，但是所有编辑器都共享功能，这是一件好事，这就是您选择的方式！

VSCode根本不像Sublime，因为它们非常不同，VSCode的目标是成为代码编辑器和IDE之间的中间地带，而Sublime则没有这样的主张，因此，VSCode的受众人群更大，从人群使用Vim到Visual Studio。

添加标签根本不是问题，人们一直说他们需要添加标签，而且我敢肯定，到目前为止，他们已经知道标签很重要，但是真正的问题是正确的设计并确保体验对于每个人，那些喜欢标签的人和那些讨厌标签的人。

现在，当您设计功能时，尤其是编辑器中体验核心的功能时，您不仅可以修改一些内容并将它们放在一起，然后再发布公告，几天后会让很多人失望！好东西需要时间！这没什么不同。 :)

eyalsk 于 2016-04-18

👍2

我喜欢工作文件的概念。当打开多个文件时，选项卡无法很好地缩放。无论发生什么情况，请保持对工作文件的控制！

helmbold 于 2016-04-18

👍1

@helmbold我真的很好奇-_how_您如何有效地使用它们？我已经试过了，我只是想不出如何弄清WF的混乱。（此外，在该问题的某个方面，团队表示工作文件实际上只是事后才想到的，而不是计划中的功能。）

anyong 于 2016-04-19

@eyalsk ：

真正的问题是正确的设计，并确保所有人，喜欢标签的人和讨厌标签的人都感觉良好。

几乎每个人都说过，正是出于这个原因，他们希望选项卡将受设置控制。话虽这么说，虽然几年前在tabs的早期迭代中使用某些软件并不是很好用，但如今这些通常都还不错。代码具有Sublime，Atom和非编辑器（如浏览器），它们的作用是使选项卡“正确”。

我希望看到的一项功能是我没有在任何选项卡式软件中看到过这种功能，并且可以缓解“选项卡过多”的某些问题，这是一种选择多个选项卡并将其拖到新窗口中的方法。

归根结底，总是缺少用于管理数百个名称相似的长文件的人机界面-这不是我们的工作方式，而是因为我们被迫工作。软件工程的当前状态。

anyong 于 2016-04-19

@anyong肯定！添加选项根本不是问题，我的意思是，当您问自己哪些选项是多余的，哪些选项实际上是有用的时，问题就开始了。原因，但主要是因为制表符不是事后才想出来的，而且，也不可能将一个编辑器与另一个甚至具有制表符的程序进行比较，主要是因为导航故事通常因程序而异，不同的程序旨在关注不同的程序东西。

仅仅因为Sublime / Atom或其他程序具有选项卡并且可以很好地运行，并不意味着您可以将所有可以运行的内容都放入该程序并将其烘焙到您的程序中，这不是工作的原理，实际上是_can_失败的原因！它在那里成功，因为整个软件包使它成功。

现在，向编辑器添加一种新的用户体验有点需要您重新评估整个导航过程，包括“工作文件”之类的现有功能，尤其是当您有现有用户并且每个人都希望它像他们选择的编辑器一样工作时您可以从帖子中看出，其中许多人对它的工作方式都有很高的标准。 :)

eyalsk 于 2016-04-19

👍1

：+1：

cnwarden 于 2016-04-19

@ bpasero ， @ bgashler1和我已经开始着手进行UX设计，以改善文档管理。我们正在仔细观察有关此问题的所有反馈，并已经与少数人进行了交流，以获取有关您自己独特的经历和观点的更多详细信息。

现在，我们想与您分享我们的早期设计，以获取您的反馈。我们将于4月21日星期四BST下午举行Google环聊。如果您想加入我们，请在那时单击此链接： https :

这将是我们的第一次公共设计会议，我们期待着它。

stevencl 于 2016-04-19

👍4

我一直在专门使用VSCode（来自WebStorm），而且我没有丢失任何选项卡。最初我以为可以，但是我开始更喜欢“工作文件”，因为我可以在更小的空间中看到更多内容，而不必考虑如何在屏幕上进行排列或分组。现在，我主要使用CTRL + TAB。

我认为，如果有任何传统选项卡应为官方_extension_或选择加入_option_。我个人希望标签以外的其他内容可以增强当前的体验。

我发现CTRL + TAB缺少的是活动编辑器窗格的上下文。如果我有2个并排打开的编辑器窗格，那么我想看到CTRL + TAB会显示文件历史记录，向下过滤到已在活动编辑器窗格中打开的文件，而不是整个应用程序中打开的所有文件（尽管那仍然需要存在）。另外，也许单击编辑器窗格顶部文件名上/附近的某处可能会显示在该编辑器窗格中打开的文件的下拉列表（与CTRL + TAB相同）。

保持良好的工作。

RyanEwen 于 2016-04-19

👍1

另一个建议。最好有一个更好的默认键组合来查看侧边栏隐藏时的工作文件列表。我最近才发现CTRL + K CTRL + P可以显示我想要的内容，但是比CTRL + TAB困难。就像我对CTRL + TAB所建议的那样，“工作文件”弹出窗口可从基于活动编辑器窗格的某些上下文中受益。也许可以对其进行排序，以使在活动编辑器窗格中打开的“工作文件”列表在其余列表的上方。

RyanEwen 于 2016-04-19

@RyanEwen我想您以前不是快捷方式用户？因为Intellij Idea平台具有相同的快捷方式，并且可以将选项卡放置在任何位置（顶部，底部，左侧，右侧，无）。将其放在“左” /“右”时，其工作方式类似于VSCode中的“工作文件”。做一些实验会很棒。使用CTRL + TAB组合和顶部选项卡返回WebStorm，以查看是否不需要它或被迫接受为唯一的解决方法。 WebStorm中的CTRL + E也是具有过滤（搜索类型）功能的“最近文件”。

任何人对Tabs都说不，也请提及您是否在工作流程中使用MOUSE。

KayLeung 于 2016-04-19

：+1：

sibelius 于 2016-04-19

👎1

@KayLeung我在WebStorm中使用了CTRL + E，但是由于有选项卡，我允许自己更多地使用鼠标来获取它们。当我无权访问VSCode时，我最近使用了选项卡式编辑器（Koding.io），可以秘密地说我不会错过设置/排列选项卡的权限。与仅具有历史相比，这似乎很乏味。我发现自己总是对我想要的东西布局和预测打开哪些文件感兴趣，而不仅仅是使用编辑器并在文件之间切换。我知道，这可能部分是“我”问题，而不是制表符问题。我猜有点强迫症。

使用WebStorm时，我是一个老鼠。我使用快捷键在这里和那里搜索最近的和未打开的文件，但是将鼠标悬停在选项卡上以查看已打开的文件。我不觉得我可以轻松/直观地用键盘输入特定的选项卡，并且渴望安排这些选项卡，这也最终使我无法接触到鼠标。缺少选项卡使我不自觉地（无痛地-在我的情况下）帮助我进入了键盘优先的工作流程。

RyanEwen 于 2016-04-19

👍1

我刚刚尝试了Adobe Brackets，并且“工作文件”列表按窗格划分。如果您具有“左”和“右”窗格，则在边栏中有2个工作文件列表（“左”和“右”），而不是VSCode中的一个。不错的解决方案。不会介意这样的事情（除了我在活动编辑器窗格的基础上向CTRL + TAB添加上下文的其他建议）。

RyanEwen 于 2016-04-19

@RyanEwen您提出了非常好的观点。对于我的IDE的任何打开实例，我总是使用2个窗格。我可能在2个屏幕上有2个打开的实例，用于4个打开的窗格。我不能完全指责它，但是您做到了。当前有两个（或更多？）打开的窗格时只有一个列表，这是当前“工作文件”实现的问题，这使我无法使用它。感谢您在此处提供具体信息。

riclf 于 2016-04-20

谨在此提醒您，我们（我自己，@

加入该链接的时间是BST下午4点： https ：

stevencl 于 2016-04-21

提醒所有计划加入视频群聊的人-它正在进行中，因此请单击上面的链接。到目前为止只有5个人。

anyong 于 2016-04-21

我本来很想去的，但是现在是11点，我无法上班。我认为之后有人会分享一些东西吗？：D

RyanEwen 于 2016-04-21

简要概述：

选项卡和工作文件（重命名为“打开的编辑器”）的行为完全相同，这仅取决于您要在顶部（选项卡）还是在左侧（打开编辑器）视觉效果
选项卡按面板在顶部视觉分组，打开的编辑器分组在标题“左”，“右”下
单击文件以打开预览选项卡（或“打开编辑器”）；双击文件，编辑文件，或双击选项卡本身以保留
调试器将所有文件作为预览文件打开，除非您采用上述任一选项来持久保存要调试的文件
标签/打开的编辑器可以在面板之间拖动
可以拖动面板以移动整个选项卡组

看起来真的很不错，而且就个人而言（如果您阅读上面的文章，则来自非常专业的小组），我想我很乐意为新的“开放式编辑器”做一个公平的尝试。

开发者的后续思路：

由于选项卡/打开编辑器的流程完全相同，因此应该可以执行以下操作：在资源管理器打开时显示打开的编辑器，在资源管理器关闭时显示选项卡。我们可以增加代码的水平空间并保持标签访问。假设有一个“隐藏/显示”选项卡快捷方式，这相当于同时按一下该快捷键和CTRL + B-如果它可以正常工作，则应在设置中选择一个选项： autoShowTabsWhenExplorerClosed 。如果需要查看更多选项卡，则可以单击V形按钮，也可以单击CTRL + B来查看左侧面板中的选项卡。我不确定这是否会“迷失方向”，但是只要打开的编辑器和选项卡始终完全相同且顺序相同，我就可以想象它会很好地工作。
我认为您提到过，在CTRL + Tab +某一种视图中可以使用以前关闭的选项卡，但是您是否想到过CTRL + SHIFT + T（撤消关闭选项卡）快捷方式，该快捷方式将只是重新打开以前关闭的选项卡（按顺序他们被关闭了）？

anyong 于 2016-04-21

❤2 👍2 🎉1 😄1

我只能加入过去15分钟左右的时间。记录了吗？

我很失望（但并不惊讶）看到选项卡可能会
成为默认值。希望您能继续保留轻量化
VS Code环境并探索渐进式工作流程。

谢谢，

詹姆士

在2016年4月21日星期四上午11：07，anyong [email protected]写道：

提醒任何打算加入视频群聊的人-现在如此
点击上面的链接。到目前为止只有5个人。
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -212963079

indiejames 于 2016-04-21

听起来好像有一些好主意。我期待看到这一行动。

FWIW（如果仍然有用），我仍然认为最好不要在UI中默认使用标签。我真正希望的是一个不错的干净的编辑器标题，如果我没有显示侧边栏或CTRL + TAB的话，可以单击它来查看文件列表。

RyanEwen 于 2016-04-21

感谢所有能够参加今天并向我们提供反馈的人。我们已做笔记，并一直在这里关注GitHub问题。我们在听大家。

@indiejames和@RyanEwen是的，我们记了笔记，我们会尽快发布。我们尚未确定默认行为。但是，我们提出了一种解决方案，使您可以轻松选择是否要使用工作文件，选项卡或同时使用两者。

bgashler1 于 2016-04-21

👍2 ❤1

@ bgashler1您提到您正在寻找一种解决方案，该解决方案将使人们可以选择是否要使用工作文件，选项卡，或者两者都不需要？这是一个选择吗？取决于我正在研究的项目和语言，对于像PowerShell这样的脚本来说，没有一个会很棒。 :)

eyalsk 于 2016-04-21

感谢大家抽出宝贵的时间参加今天的电话会议并提供反馈，我们非常感谢。 @anyong在总结我们介绍的

视觉设计

首先，此图表明了我们认为标签在VS Code中的外观：

我们的目标是打造轻巧，不引人注意的外观，使其与VS Code的其余部分非常吻合。我们还没有拟定一个浅色主题的外观。

如上图所示，选项卡在名称左侧包含一个关闭按钮。当文件中包含未保存的更改时，我们会在关闭按钮的位置显示一个脏指示器。

将鼠标悬停在选项卡上将显示一个工具提示，其中包含选项卡中文件的完整路径。

预览标签

为了清楚地将预览选项卡与打开的选项卡区分开，我们将选项卡中的标题用斜体表示，如以下线框所示。

我们讨论了将预览标签提升为完全打开标签的操作：

在标签内编辑内容
双击资源管理器中的文件
双击选项卡组中的预览选项卡

溢出

选项卡在活动选项卡的右侧打开。如果没有足够的空间来显示选项卡组中的所有选项卡，我们将使选项卡溢出。我们不会在选项卡内截断文件名，以便为更多选项卡腾出更多空间。

每当有溢出时，我们就会显示人字形。单击该人字形框将显示一个快速打开的对话框，其中列出了选项卡组中的所有选项卡，从而使用户可以找到他们要查看的选项卡。

单击当前溢出的选项卡将显示该选项卡。

导航标签

以下命令允许用户在选项卡之间导航：

Ctrl-Tab显示活动选项卡组内所有选项卡的列表：
Ctrl Alt选项卡显示所有选项卡组内所有选项卡的列表
快速打开显示所有选项卡的线性历史记录

工作档案

我们重命名了工作文件以打开编辑器，以更好地反映出它的真正含义。

打开的编辑器列表的作用与选项卡相同。我们只是在浏览器中列出它们，而不是将它们可视化为选项卡。

如果一个文件在两个或多个编辑器组中打开，我们将在打开的编辑器列表中显示此文件：

用户打开的任何编辑器都会显示在打开的编辑器列表中。因此，例如，差异编辑器显示如下：

每个组仅包含一个预览选项卡。

活动编辑器组右上方的V形符号表示是否有一堆编辑器。

在这种情况下，关闭编辑器将在堆栈中显示其下方的编辑器，而不是完全关闭编辑器。

关闭编辑器（例如，使用Ctrl-W）也会从打开的编辑器列表中删除该编辑器。

stevencl 于 2016-04-21

👍221 ❤64 🎉63 😄23

@stevencl

为了清楚地将预览选项卡与打开的选项卡区分开，我们将选项卡中的标题用斜体表示，如以下线框所示。

除了将其斜体化之外，如果可以将选项卡的颜色变暗以使其_really_清晰，则可能会很棒。

就像我之前写的一样，我也想知道是否有一个选项卡根本没有选项卡或没有打开编辑器，这对于执行脚本的人员（例如PowerShell）可能是有用的方案。

eyalsk 于 2016-04-21

👍14

@eyalsk在讨论中提到，应该分别对选项卡和打开的编辑器启用/禁用/禁用/禁用。

anyong 于 2016-04-21

👍8 ❤4

@anyong谢谢！ :)

eyalsk 于 2016-04-21

Ctrl-Tab显示活动选项卡组内所有选项卡的列表：

最后！是否制表符，这是我一直在等待的行为！我的文件历史记录再也不会丢失。

关闭编辑器（例如，使用Ctrl-W）也会从打开的编辑器列表中删除该编辑器。

大！希望这会更直观，并有助于清除_工作文件_中的混乱情况。

现在，我将等待https://github.com/Microsoft/vscode/issues/5554关闭。

csholmq 于 2016-04-21

👍1

嗯，我不知道是否考虑过这个问题，但是我刚才想到了，多台显示器支持！在Visual Studio中，我可以将选项卡拖动到其他监视器上并创建新的选项卡窗口/视图，是否正在考虑使用这种方法？我想可以通过创建一个新的VSCode进程并通过进程间通信在进程之间拖动选项卡来实现这一点，对于开放式编辑器也是如此，只是一个主意，:)

eyalsk 于 2016-04-21

👍14

拜托，拜托，拜托，您可以将“预览标签”设置为可选-即可以选择将任何内容自动升级为永久标签，并且永远不会消失。我知道您正在讨论以视觉方式区分临时标签的方法，但坦白说，这种方法不适用于像我这样快速在文件之间导航的人（尤其是Go-To-Definition等），以至于没有时间目视检查选项卡以了解其行为，我不记得我如何打开文件或是否碰巧对其进行了编辑，并且当文件似乎随机消失时，我发现它确实令人不安。（我知道这不是随机的，但也可能是随机的。）

我通常将自己埋在打开的选项卡中，直到完成一个工作单元，然后在我提交的同时将它们全部关闭。

stephenmartindale 于 2016-04-21

👍12

谢谢@eyalsk ，是的，我们确实考虑过。最终，我们希望能够对此提供支持，但是在多个进程之间共享上下文所需的工作非常重要，因此在处理文档管理UX的其余部分时，这不太可能发生。这绝对是我们想要做的。

stevencl 于 2016-04-21

👍3 ❤2

@stevencl如果拖动只是打开了一个新的vscode窗口（文件也打开了），我会很高兴。

Tyriar 于 2016-04-21

👍4

感谢@Tyriar ，我们将继续研究这个问题。如果有一种方法可以使它运作良好，我们很乐意能够做到。

stevencl 于 2016-04-21

❤1 👍1

@stevencl我只是担心将来会需要更多的工作来添加它，因此，当您改进基础结构时，请确保将其保留在积压的工作中！ ;）

eyalsk 于 2016-04-22

标签

shuson 于 2016-04-22

很高兴看到这个。喜欢轻量级的建议，您正在寻找一种不破坏工作文件体验的方法。

期待尝试一下。谢谢收听。

glennblock 于 2016-04-22

@stevencl似乎两全其美。看起来很棒！这些选项卡的显示与我期望的一致，以便与UI的其余部分相适应，并且听起来好像我可以通过工作文件的更改获得我想要的东西：)

Open Editors是否支持两个以上的编辑器组？只是想知道如何命名它们是否比Left和Right更复杂。

RyanEwen 于 2016-04-22

是的，这仍然会受到支持。

来自：Maxime Quandallemailto：[email protected]
发送：22/04/2016 23:09
至：Microsoft / vscodemailto：[email protected]
抄送：史蒂文·克拉克mailto：[email protected]; Mentionmailto：[email protected]
主题：回复：[Microsoft / vscode]打开文件的正确选项卡（＃224）

在@stevencl提案下，仍然可以通过拖放来重新定位窗格吗？

您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看：
https://github.com/Microsoft/vscode/issues/224#issuecomment -213605667

stevencl 于 2016-04-23

@stevencl我认为您几天前在讨论中概述的内容很棒。这正是我们所有人一直在等待的关于选项卡的内容。我使用的其他一些编辑器还实现了水平和垂直面板配置。这样一来，您可以在顶部并排打开两个文件，而在其下方打开一个或两个文件。尽管这不是一项关键功能，但在开发前端Web应用程序和移动应用程序时，我确实发现自己经常错过这一功能。原因是我从事的大多数工作是MVC或其衍生产品，因此同时打开模型，视图，控制器和某些UI文件（css，Js等）是一个巨大的好处。是否有计划将其包括在内？ Atom确实做得很好，这是我在VSCode之前使用的最后一个编辑器。不幸的是，它在VSCode擅长的其他领域中严重缺乏，因此我仅使用VSCode。如果不在计划的发行版中对选项卡和文档管理进行更改，则这将是未来的重大改进。

jayrosen1576 于 2016-04-23

@ jayrosen1576在此问题中捕获了水平分割https://github.com/Microsoft/vscode/issues/1749 ，请确保：+1：以表示您的兴趣。

Tyriar 于 2016-04-23

好的工作人员，线框看起来真的很好用。

rjmacarthy 于 2016-04-27

嘿@stevencl
感谢您的出色工作，这是我的2美分，位于左侧的关闭按钮。
当打开许多文件且选项卡缩小时，每个选项卡的小空间仅足以显示关闭按钮，这将使意外关闭选项卡而不是选择它变得容易。

脏污指示器图标仍可以保留在左侧，因为它仅指示文件状态，但是向右移动关闭按钮将使我们轻松识别文件名，并防止意外的关闭动作。

hsyn 于 2016-04-28

@stevencl样机看起来很棒，并且功能描述很

TurkeyMan 于 2016-04-28

@hsyn是我的理解，这些选项卡不会缩小，并且可以从V形溢出按钮获取溢出选项卡。关闭按钮不应该成为问题。

anyong 于 2016-04-28

选项卡在活动选项卡的右侧打开。如果没有足够的空间来显示选项卡组中的所有选项卡，我们将使选项卡溢出。我们不会在选项卡内截断文件名，以便为更多选项卡腾出更多空间。

我不同意。如果将屏幕分为2-3列，则最多将显示1-2个选项卡，其余的将溢出。拜托，请做浏览器的工作，我们每天都在使用它们，这很直观，而且我们已经习惯了。我鼓励您使用已建立的模式，其中一些已经发展了十多年。不要反对谷物。

alexgorbatchev 于 2016-04-28

我不同意。如果将屏幕分为2-3列，则最多将显示1-2个选项卡，其余的将溢出。拜托，请做浏览器的工作，我们每天都在使用它们，这很直观，而且我们已经习惯了。我鼓励您使用已建立的模式，其中一些已经发展了十多年。不要反对谷物。

某些浏览器会组合使用缩小的标签，但随后会使标签溢出，超出某个阈值。 Firefox做到了；可以肯定的是，iOS Safari也做到了（或做到了）。

当打开了足够多的选项卡而您几乎看不到每个字母时（尽管在实践中我通常没有那么多字母），它没有比溢出更有用的了。

kfranqueiro 于 2016-04-28

@alexgorbatchev我绝对知道您来自哪里，但这是他们前几天在电话会议上解释的内容-从另一个角度看，有很多打开的选项卡并且无法读取其中任何一个的名称是也不是一个好的解决方案。 “溢出”是根本没有标签与缩小的标准“ Chrome样式”标签之间的一种折衷。强制选项卡至少显示文件名意味着可见选项卡将至少有用。

但是您确实为开发人员提供了一个想法-我认为这里的真正问题是，尽管我们知道当所有文件名都隐藏时我们不能使用20个标签，但至少我们知道有20个标签可以打开，并且为我们提供了某种感觉“我知道如果需要我的文件，它们不会消失。” 只需修复一个指示器即可显示当前隐藏的选项卡的数量，指示器可以在溢出V形字形上方一个小圆圈，以免占用任何额外的水平空间。

anyong 于 2016-04-28

谢谢大家。我们没有在模型中显示它，但我们的意图是在需要时缩小标签，以便仅显示文件名和关闭按钮。由于@anyong提到的原因，我们不希望缩小到文件名之间无法区分的地步。我们认为，代码编辑器中的多个选项卡具有相似的名称比浏览器选项卡具有相似的名称（例如，可能有许多具有相同前缀的文件名）更常见。因此，我们认为代码编辑器中的选项卡缩小与浏览器中的选项具有不同的后果。

我们打算显示带有双V形燕尾形的选项卡何时处于溢出控件中，但放置带有多个选项卡溢出标记的徽章也是一个有趣的想法。数字的意图仅仅是表明存在溢出选项卡，还是溢出选项卡的实际数量很重要？

stevencl 于 2016-04-28

感谢您清除@stevencl。

选项卡中文件名要记住的一个极端情况是从不同文件夹（index.js，README，LICENSE，package.json等）打开的多个具有相同名称的文件。

alexgorbatchev 于 2016-04-28

我可能根本不会使用标签页，但是我也值得指出
浏览器通常会在标签中显示网站的网站图标
即使选项卡缩小到超过
这是可读的。源文件没有图标可消除歧义，
正如史蒂文指出的那样，文件名在源代码中通常是相似的。

2016年4月28日，星期四，12：16 PM，史蒂文·克拉克（Steven Clarke） [email protected]
写道：

谢谢大家。我们没有在模型中显示它，但我们的意图是
在需要时，我们将缩小标签，以便仅
文件和关闭按钮可见。由于@anyong的原因
https://github.com/anyong提到，我们不希望缩水到
文件名不可区分的一点。我们认为
在代码编辑器中使用多个标签可能更常见
与浏览器标签具有相似的名称（例如，
可能会有许多文件名带有相同的前缀）。因此我们认为
在代码编辑器中缩小选项卡所产生的结果与在
浏览器。
我们打算使用双精度显示标签在溢出控件中的时间
人字形，但要在徽章上贴上溢出的标签，这是一个
有趣的想法。目的是数字只是表明
有溢出选项卡，还是溢出选项卡的实际数量重要？
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -215481474

indiejames 于 2016-04-28

谢谢@alexgorbatchev。对于在这些情况下如何显示文件路径以便能够消除歧义，我们有一些想法。例如，在上面显示的高保真模型中，我们在文件名下方显示文件的路径。不过，这只是一个主意，如果路径很长，则可能行不通。另一个方法是将路径放入状态栏中。有很多值得探索的地方...

stevencl 于 2016-04-28

@stevencl

数字的意图仅仅是表明存在溢出选项卡，还是溢出选项卡的实际数量很重要？

我认为显示打开的选项卡的实际数量（但从视图中隐藏）可以解决问题。从本质上讲，人们已经习惯于看到这种情况（嗯，至少是为我自己说话）：

因此他们凭直觉就对“我打开了很多标签”和“我打开了2或3个标签”有了一些了解

与显示20个细小/无用的缩小的标签相比，显示“ 20”的徽章要小得多（本质上没有多余的空间），但是它仍然使我立即知道（a）隐藏的标签在那里，以及（b）有很多。

anyong 于 2016-04-28

😄5

我只是这个线程的新手，但我的2p作为完整的VS2015用户：

期待在vscode中使用制表符，因为工作文件永远不适合我（尽管我现在看到按ctrl-f4并不会像我想象的那样从该集合中删除）。

预览标签的忠实支持者，很高兴看到它的加入。

好奇为什么新标签会在活动标签的右侧打开。我期望答案是“因为网络浏览器”或“因为崇高”，但这对我来说似乎是违反直觉的，特别是如果选项卡通过从左侧隐藏（进入右侧的V形）而溢出。

我希望按照VS看到选项卡的右键菜单...最重要的是，“全部关闭”（针对组），不要为“除此以外的全部关闭”而大惊小怪。所有修改后的文件的VS样式保存框在这里将很有用。

左边的关闭按钮对我来说很奇怪-我认为这是一些mac / linux约定-但只要选项卡上的“单击中间按钮”会关闭编辑器（如果适用，则提示保存），然后再打扰。我可以看到为什么要连续快速关闭一堆文件的原因，但无论如何，单击中键还是比较好的（尽管对于不带滚轮的Mac或笔记本电脑却不是这样）。

雪佛龙文件选择器应允许键入以快速跳转到文件。并不是我个人计划打开足够的文件来显示人字形（并且，当我这样做时，我无疑会使用ctrl-p），但是确实发生了。

人字形数字-这是该组中_hidden标签/文件/编辑器的数量，还是_all_包括可见文件的数量？我只争论隐藏的项目，尤其是当某些东西从选项卡行溢出时，如果仅显示人字形（以及计数）的话。

稍微相关一点，如果我使用ctrl-f4（或ctrl-w？似乎是ctrl-f4的非Windows版本，除非我弄错了），我希望如果选项卡消失了，它将关闭编辑器，应提示您保存/丢弃并将其从ctrl-tab / ctrl-alt-tab /工作文件中删除...我可以看到目前可以进行一些按键绑定更改以启用此功能，但是我很难看看为什么在基于选项卡的界面中，选项卡的存在与文件/编辑器的“当前” /打开状态不直接相关。

爱你们在vscode上所做的一切，看起来很棒amazing

maxcalvin 于 2016-04-29

我尝试按照建议的方式使用文件历史记录，一个月后，我不再需要任何标签。在VS中，打开一堆标签确实很烦人。太多时，我会讨厌它，然后进入隐藏选项卡的小下拉菜单。我想我现在也真的很想在VS中使用文件历史记录。

关于工作文件，我发现所有内容都令人讨厌。烦人的是，我从不打开它并保持关闭状态。我觉得对您有用的唯一一件事就是看到尚未保存的新文件，或者我想是尚未保存的任何文件。它很快变得太大了，我什至无法关心。不确定如何解决。也许只显示未保存的文件，但这会有一些怪异的副作用。

无论如何，我现在是文件历史记录的信徒。 :)

JoshClose 于 2016-04-29

👍5

我认为，如果我们可以使用shift+cmd+[和shift+cmd+]来增加在历史中来回移动的能力，那将真的很酷。这些是在其他应用程序中的选项卡之间导航并能够使用它们来导航历史记录的默认快捷方式，我认为这至少可以使我至少成为一个信徒

编辑：基本上是通过实现

  { "key": "shift+cmd+[", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+]", "command": "workbench.action.openPreviousEditor" },
  { "key": "shift+cmd+[", "command": "workbench.action.quickOpenNavigateNext", "when": "inQuickOpen" },
  { "key": "shift+cmd+]", "command": "workbench.action.quickOpenNavigatePrevious", "when": "inQuickOpen" }

作为自定义键绑定

that70schris 于 2016-04-29

👍2

我认为能够将代码段拆入新窗口也将很有用。虽然不确定那件事是否可能。

JoshClose 于 2016-04-29

👍1

@JoshClose完全有可能，但是它们缺乏用于编辑器本身的进程间通信的基础结构，因此对于两个实例进行通信并执行其首先需要具有协议的所有操作。

eyalsk 于 2016-05-01

...选项卡在名称左侧包含一个关闭按钮

是否有违反约定的特定原因？读取LTR时，最重要的信息是文件名，而不是关闭按钮。将其向右移动还可以使关闭按钮在默认情况下处于隐藏状态（并悬停显示）变得更加容易。在稍后的阶段，用户可能还希望在文件名的左侧具有文件图标。

我们讨论了将预览标签提升为完全打开标签的操作...

我认为前两个选项可能就足够了。双击选项卡可能对将来的其他事情很有用。

对于在这些情况下如何显示文件路径以便能够消除歧义，我们有一些想法。

将鼠标悬停在选项卡上时，仅显示工具提示（带有相对路径）怎么办？这样可以减少设计的混乱程度，凸耳也不必那么高。

每当有溢出时，我们就会显示人字形...

Firefox可以很好地处理选项卡溢出–它具有最大的选项卡宽度，向左/向右滚动按钮，列出所有选项卡的下拉菜单（标记了当前可见的选项卡）等。

glen-84 于 2016-05-01

👍4

如果选项卡关闭按钮符合平台约定，那将是非常不错的选择：OS X的左侧，Windows的右侧。

coreh 于 2016-05-03

👍10

在使用VSCode一段时间后，我认为_Working Files_模式对我来说已经成长了很多！

原因如下：

尽管听起来有点违反直觉，但是关闭我不使用的文件（ctrl-w）并不能将其从工作文件中删除。这非常好，因为很多时候我发现自己在使用相关文件（或子类）时重新打开最近关闭的文件（在React项目中）。因此，当我感觉应该关闭文件时，并不与我应该关闭文件时一一对应。
我喜欢由workbench.files.action.closeFile提供的显式Force-Close。
我将workbench.files.action.closeFile重新映射到Ctrl + k Ctrl + w，因为它比Ctrl + kw需要（略）少的工作量，
我可以在编辑器的顶部栏中看到完整的文件名和路径->这在深度嵌套的项目（如我拥有的项目）中非常重要，该项目具有类似或相同名称的文件（ index.js ？），并且仅区别的方法是通过路径。
更少的杂音=禅宗！

因此，以某种方式，我想说的是，如果您引入了Tabs，请不要删除当前的流程。

kumarharsh 于 2016-05-04

👍5 ❤3

@kumarharsh为什么他们要删除它？如果有的话，他们可能会为您改善！ :)

eyalsk 于 2016-05-04

如果脏指示器替换了CLOSE图标，那么如果我们不想保存所做的更改，我们将如何关闭文件？ ctrl-w仍然可用吗？

rojorojo 于 2016-05-04

脏指示器不能仅更改为悬停时的关闭按钮吗？
这是一个很常见的解决方案...

在2016年5月4日星期三晚上11:28，rojorojo [email protected]写道：

如果脏指示器取代了CLOSE图标，我们将如何
如果我们不想保存更改，请关闭文件吗？ ctrl-w仍然是
有空吗
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -216901750

anyong 于 2016-05-04

👍3

@rojorojo我们正在按照@anyong的建议进行操作，因此您不会遇到任何麻烦。是的，Ctrl + W仍然可用。

bgashler1 于 2016-05-04

感谢您的所有反馈。

本月底，我们将对最新设计进行用户体验研究。如果您在5月25日或26日有一个小时的时间想参加研究，请在此处注册： https :

不幸的是，我只能提供白天的时间（英国夏季时间），而不能在晚上进行会议。

我们希望有一些可以试用的工作位，以及一些我们尚未显示的设计线框。

stevencl 于 2016-05-05

等等，我喜欢当前的UI行为，会有配置吗？

be5invis 于 2016-05-06

👍6

三个星期前，我真的很想要标签。由于没有选项卡，我什至推迟了一段时间切换到VSC。现在，我已经花了几周时间使用VSC，我什至不需要标签。在这一点上，我认为他们会妨碍我。

我希望当它构建时将是可选的，以便我们中那些想要它的人可以在当前环境中继续使用。

MrTravisB 于 2016-05-09

👍11 ❤1

作为一个真正喜欢垂直选项卡的人（它们的缩放性更好，并且在宽屏显示器上也能更好地工作），我想知道：为什么同时需要选项卡和“开放式编辑器”。如果后者基本上是具有选项卡行为的“工作文件”，那么这就是我所需要/想要的。

rauschma 于 2016-05-10

👍6

我要投票以确保这些选项卡是可选的。我真的不喜欢编辑器选项卡，非常喜欢窗口左侧的面板。我了解为需要它们的人添加它们，但是请不要强迫他们。我不喜欢它们是关于此编辑器的一件事。

marcusrugger 于 2016-05-10

👍12

我的两分钱：我永远不需要关闭按钮；对我来说，它们是浪费房地产，有时会造成挫败感（偶然点击）。意外地中键单击比意外地向左单击1px困难得多。

我还认为肮脏的指标浪费了房地产。在Sublime Text中，我将“ dirty”配置为仅更改选项卡的字体颜色。过去，我也将其设为斜体，但听起来您已经计划了将预览斜体。

OlsonDev 于 2016-05-10

👍2

边框的左侧太宽

awkr 于 2016-05-10

@ be5invis @MrTravisB @rauschma @marcusrugger @jpaaso

伙计们，我知道这是一个漫长的话题，所以您可能没有全部阅读，但是请阅读此处的文章。选项卡是可选的，开发人员已经非常非常了解您要提出的要点。

可能的张贴者：请仔细阅读主题，看看问题是否已经得到解决-每次发布时，都会有一百个人收到您的电子邮件：+1：谢谢

anyong 于 2016-05-10

👍5

@anyong但是，如果您打开两列，则“打开编辑器”
请将此选项设为可选。

be5invis 于 2016-05-10

@ be5invis唯一的区别是有一个视觉分隔符。您仍然可以拖动文件，然后在所需的任何编辑器中打开它们。

anyong 于 2016-05-10

@anyong我可以藏起来吗？并且，如果我选择在一个编辑器列中隐藏“分隔符”和Ctrl-Tab，是否可以切换到另一列中的打开文件？员工想要的是完全维持现有行为。

be5invis 于 2016-05-10

我上面链接的评论中的@ be5invis ：

Ctrl Alt选项卡显示所有选项卡组内所有选项卡的列表

因此，是的，您仍然可以根据需要设置键绑定以保留当前的Ctrl + Tab行为。

anyong 于 2016-05-10

👍1

@anyong很好。
但是仍然可以隐藏“左/右”指示符并使列表看起来像一个整体吗？

be5invis 于 2016-05-10

这将是@stevencl的问题

anyong 于 2016-05-10

好极了！希望我们能尽快获得标签！

NicoleZA 于 2016-05-10

好消息..我们正在获取标签..但是我们不想丢失“工作文件”文件夹。将其与标签一起保留吗？

vinod-a-ext 于 2016-05-10

👍2

太棒了！标签组

Burnett01 于 2016-05-10

@ be5invis是的，一旦您分割了编辑器，我们打算在打开的编辑器列表中显示多个编辑器组。但是您无需执行此操作即可处理多个文件。您将拆分编辑器以一次查看多个文件。如果您只是随时保持一个编辑器可见，您仍然可以打开多个文件。例如，在此屏幕截图中

我打开了两个文件，但由于没有拆分编辑器，因此仅查看其中一个文件。打开的编辑器列表显示了两个文件，我可以在那里或通过右上角的溢出控件与它们进行交互。（请注意，这里没有显示任何标签-这是“无标签”选项。）

我们这样做的原因是，在当前工作文件设置中管理在两个编辑器中打开的文件时，可能会造成混乱。例如，在当前产品下面的屏幕截图中，当我关闭工作文件列表中的app.js文件时会发生什么。两位编辑应该关闭还是只其中之一。如果只是其中之一，哪一个？

我们希望避免任何歧义和不确定性，因此我们选择了更明确地说明每个编辑器组中打开的文件。

这就是为什么我们将工作文件重命名为开放编辑器的原因，因为我们认为它更好地反映了新行为。

stevencl 于 2016-05-10

👍5

像Sublime Text一样，需要增强Go To Definition（F12）选项（即使“定义”位于项目的另一页中）也是如此？自从我安装VS代码以来，我就长期以来就遇到这个问题？对此有任何帮助吗？

vinod-a-ext 于 2016-05-10

@ vinod-a-ext-请打开一个新问题，描述您在“转到定义”中遇到的问题。

stevencl 于 2016-05-10

@stevencl
转到VS Code中的定义问题
https://github.com/Microsoft/vscode/issues/6238

vinod-a-ext 于 2016-05-10

@stevencl我的意见是，您可以将标签隐藏在“打开的编辑器”中，并只需画一条线来代表不同的面板即可。面板关闭后，可以自然合并两个列表。

be5invis 于 2016-05-10

👍2

感谢您的建议，我们一定会为此探索不同的视觉处理方法。

日期：2016年5月10日，星期二04:06:34 -0700
来自： [email protected]
至： [email protected]
CC： [email protected]；提及@ noreply.github.com
主题：回复：[Microsoft / vscode]打开文件的正确选项卡（＃224）

@stevencl我的意见是，您可以将标签隐藏在“打开的编辑器”中，并只需画一条线来代表不同的面板即可。面板关闭后，可以自然合并两个列表。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看

stevencl 于 2016-05-10

👍1

我很好奇，您使用什么程序来生成模型，像这样的程序

paranoid-android 于 2016-05-10

我们将PowerPoint用于这些模型。我们的目的是专注于交互流程，而不是视觉设计，因此PowerPoint中的工具可以很好地满足该级别的细节要求。在PowerPoint中执行操作还可以使我们轻松地将一系列屏幕串联在一起，以更好地了解流程。

日期：2016年5月10日，星期二05:03:55 -0700
来自： [email protected]
至： [email protected]
CC： [email protected]；提及@ noreply.github.com
主题：回复：[Microsoft / vscode]打开文件的正确选项卡（＃224）

我很好奇，您使用什么程序来生成模型，像这样的程序

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看

stevencl 于 2016-05-10

😄1

看到4月发行说明后才来到这里。线程打开了很长时间-但我对原始设计+1，即没有制表符。最初它困扰着我-但是后来我变得欣赏和理解其背后的哲学...现在，当我想到Atom和Tab垃圾邮件时...我发抖。除了所有这些-我喜欢开发人员的参与以及周到的评论和反馈。

lucidtech 于 2016-05-10

👍4 👎3 ❤1

期待尝试一下。我想看到的一件事是将多个相关文件合并到一个选项卡中（类似于VS插件）

这对于保持Angular 2开发的组织性非常有用，在Angular 2开发中，您通常具有相关文件：

widget.component.css
widget.component.html
widget.component.ts
widget.component.spec.ts

mattwilson1024 于 2016-05-10

👍2 ❤1

同意@lucidtech，我们曾经使用过“工作文件”文件夹。我认为选项卡可以与这个很棒的选项结合使用吗？

vinod-a-ext 于 2016-05-10

我同意@coreh的观点，即关闭选项卡按钮的位置应与平台约定相匹配。当我从Visual Studio移到Visual Studio Code时，具有关闭按钮的位置更改将是一个相当令人沮丧的上下文切换。

AshleyGrant 于 2016-05-10

我的两分钱：我之所以喜欢Atom，Sublime或其他（赶时髦的）时髦编辑器的代码，原因之一是它没有试图在Web浏览器的“标签”概念中费劲。传统的IDE（例如Visual Studio，IDEA和Eclipse）也都可以做到这一点。另一方面，代码具有“框架和缓冲区”方法，类似于您在Emacs（我相信也是Vim）中可以找到的方法。

不可避免地，在任何基于选项卡的编辑器中，我都发现自己不得不处理结果，因为编辑器框架中的选项卡非常小，这些标签的表链非常小，无法读取。此外，当我使用等效于Ctrl /⌘-PI的编辑器时，最终会变形为另一个框架，作为我第一次导航至文件时所查看的那个框架的假象。为了在另一个框架中查看同一文件，您必须执行一个笨拙的“ split tab”操作，在许多此类编辑器中，该操作通常还常常与分割框架结合在一起。 _选项卡将文件缓冲区状态与显示器上的给定帧紧密耦合。

如果您想在情感上找个借口，请_请不要将VS Code变成另一个选项卡式编辑器。

我认为，从用户体验的角度来看，与其盲目地实现选项卡以匹配Atom或任何其他编辑器的行为，不如找出人们为什么希望使用选项卡（不仅仅是舒适的熟悉程度），看看是否有一种更具创新性的解决方案可以提供指导。他们的需求是可能的。我当然同意当前的工作空间机制可以继续发展：正如其他人提到的那样，在同一个项目中（相当于基于选项卡的“提取”）打开一个单独的窗口，以便更好地利用多头显示器！

编辑：非常遗憾，我错过了19天前的通话。如果我知道的话，我会加入的。仅从1.1.0的发行说明中找到。 :(

orospakr 于 2016-05-10

👎8 👍6

制表符对我来说是必须的，另外一个建议，例如对相关文件的angular 2.0分组制表符也是一个好主意。如果功能是可配置的，那么偏好不同的用户也会很满意。我们什么时候可以尝试!!!!!!

Fiontan 于 2016-05-10

@orospakr ，您可以通过菜单选项关闭Sublime中的选项卡。仅供参考。

marcusrugger 于 2016-05-10

@orospakr

找出人们为什么要使用制表符（不仅仅是舒适的熟悉程度），并查看是否有可能针对他们的需求提供更具创新性的解决方案，将很有帮助。

关于为什么人们除了熟悉之外还需要标签，有大量反馈，更不用说如果熟悉并且人们对此感到满意，那么在已有的东西可以工作的情况下，进行创造性的创新是没有意义的。

他们尝试通过“工作文件”进行创新，一个小组喜欢它，另一个小组不喜欢它，今天我们在这里要求标签！我不希望您再次发生相同的综合症...

正确的方法是先获得人们正在寻找的经验，然后在alpha构建过程中和/或作为选择进行附加功能，创新或实验。

在这种情况下，使用选项卡/“开放式编辑器”或明天其他方式使它们成为可选的，这就是人们应该具有选择参与或退出体验的能力的方式。

eyalsk 于 2016-05-10

我知道我在这里玩游戏有些迟了，但是关于本节：

我们讨论了将预览标签提升为完全打开标签的操作：
在标签内编辑内容
双击资源管理器中的文件
双击选项卡组中的预览选项卡

我想要求在上面的列表中包括“添加书签”。
我发现将书签添加到大文件中，然后无意间单击另一个文件，关闭了工作文件，这非常令人沮丧。

我不太可能在要立即关闭的文件中添加书签。

muellerkyle 于 2016-05-10

搜寻了尽可能多的评论，寻找关键字，却没有找到提及的内容。

就制表符而言，首先，_谢谢！_他们的缺席是我对VS Code唯一不满意的事情之一。

我希望看到选项卡之间的导航可自定义；例如，我喜欢iTerm通过按cmd + left在选项卡之间切换的方式，因此非常希望在编辑器中也能做到这一点。

感谢您的出色编辑<3

cestlou 于 2016-05-11

选项卡对我来说是必须的。切换回Sublime，直到有了选项卡。 PS：我对您的态度非常失望；您似乎对UX没有任何了解，但声称已完成此操作来改善UX。你的角色是什么？您的用户面试在哪里？证明给我看。

asadighi 于 2016-05-12

👎23 😕1

@asadighi在发布之前，您甚至没有阅读评论？该团队进行了广泛的采访，并且正在进行更多工作以使选项卡正确。他们对社区的反应令人难以置信，并且正在产生一位出色的编辑（免费）。祝您在Sublime的下一个发布中好运。

indiejames 于 2016-05-12

👍15 👎1

您之前的评论表明您的偏见。我的反对意见是他们一开始就抱有的态度。用户面谈应该在人们开始抨击此类缺陷之前进行。足够有趣的是，您会发现以更好的UX的名义进行投资来修复此缺陷的意愿。此问题自11月以来一直存在，在这段时间的大部分时间里，大多数答复都符合我们的判断，比您更清楚如何完成工作。

asadighi 于 2016-05-12

👎19

@asadighi一切都在您的脑海中，您的废话在您的评论中显示，请停止。

eyalsk 于 2016-05-12

👍7

@muellerkyle ：+1：您应该针对您使用的书签扩展名创建一个问题。

Tyriar 于 2016-05-12

我很期待这个功能

lroronoazoro 于 2016-05-13

+1！

MJLHThomassen 于 2016-05-15

每天，我在Eclipse，PhpStorm，Notepad ++和VSCode之间切换。猜猜是什么， CTRL+W让我发疯。

Namek 于 2016-05-16

我参加这个聚会很晚，但是这些选项卡是可选的吗？我曾经以为我想念他们，但现在我没有。只是好奇是否有办法隐藏它们。不要讨厌标签和想要使用标签的人，只是认为我更喜欢使用切换来显示/隐藏。这一切都保持了出色的工作。我喜欢vscode。

jamesmenera 于 2016-05-16

👍4

@jamesmenera是的，它将是可选的，但工作文件也是如此（打开的编辑器）。

eyalsk 于 2016-05-17

顺便说一句，您会透露用于制作这些模型图片的程序吗？

ciel 于 2016-05-17

@ciel ， @stevencl写道，他们为此使用了PowerPoint。

就个人而言，我喜欢WireframeSketcher，但PowerPoint也可以。 :)

eyalsk 于 2016-05-17

就像@jamesmenera提到的那样，我真的很想念选项卡和边栏，但我可以看到很多人喜欢“工作文件”方法，因此它应该是可选的。

djedlajn 于 2016-05-17

@ kadza93选项卡和工作文件都将是可选的...我想知道我要写多少次。

搜索并查找“可选”一词确实很容易，与实际撰写有关该信息的帖子相比，查找您将花费更少的时间！

eyalsk 于 2016-05-17

@eyalsk我不知道为什么会发火焰！我是在这里表达我的需要，据我所知，我需要很多人使用选项卡，因此，通过支持他人所说的并同意，我做错了什么？顺便说一句，感谢您对搜索功能的提示，我应该在长线程上更多地使用它，在这里我要表达我的观点，如果有人已经表达了类似我的观点，我将跳过它。

djedlajn 于 2016-05-17

距离您的帖子只有3个...

JoshClose 于 2016-05-17

遵循此主题，在我看来，对于将来的发行版，选项卡上已经做出了一些决定（选项卡是可选的，其中将显示图标，组合键等）。如果我没记错的话，有没有人可以指出的这些决策清单？

jtlowe 于 2016-05-17

@jtlowe没有什么简单的方法可以使它变得显而易见，就像在GitHub上固定评论一样。人们发表新评论，它掩盖了重要内容。当评论过多时，GitHub也会折叠注释，这会使在页面中查找变得困难。

Tyriar 于 2016-05-17

也许管理员可以在问题页面顶部（在OP的问题正文下方）放置“当前状态：开发中”横幅？

这应该是github中的适当功能---类似于此处的alt-文本建议： https :

kumarharsh 于 2016-05-17

@ kadza93我没有向你

我是在这里表达我的需要，据我所知，我需要很多人使用选项卡，因此，通过支持他人所说的并同意，我做错了什么？

不，您没有做错任何事情，但是您也没有写任何有用的信息，表情符号/反应功能正是出于这个原因而存在。

顺便说一句，感谢您对搜索功能的提示，我应该在长线程上更多地使用它，在这里我要表达我的观点，如果有人已经表达了类似我的观点，我将跳过它。

是的...您很有道理，我的意思是对已确认的事情发表意见！而且您甚至不需要搜索它，因为我回复了您竖起大拇指的那个人。

通常，在很长的帖子中搜索可能的常用词是常识。

eyalsk 于 2016-05-17

确实，开发人员应该使用FAQ和从
该线程中最常见的要点，并解决此问题。人
订阅此问题的用户每天都会收到数十封电子邮件
相同的“竖起大拇指” /“竖起大拇指”注释。
在2016年5月18日上午1:51，“ Kumar Harsh” [email protected]写道：

管理员可以在上面放置“当前状态：开发中”标语
问题页面的顶部（在OP的问题正文下方）？
这应该是github中的适当功能---类似alt-text的东西
这里建议： https :
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -219798727

anyong 于 2016-05-17

@anyong是的，我完全同意！没什么好讨论的，一旦tabs和open editors生效，他们应该创建两个单独的问题，以获取有关这些功能的反馈。

eyalsk 于 2016-05-17

@eyalsk我们仍在尝试如何处理有关社区创建的问题的更新。有很多方法可以做到这一点，但是如果没有GitHub上的固定评论功能，它们都是不好的。到目前为止，集成终端问题https://github.com/Microsoft/vscode/issues/143#issuecomment -213581854很好，并且在线程中间进行了大的更新，我想这与讨论的需要减少了所以它还没有被掩埋。

Tyriar 于 2016-05-17

@Tyriar好吧，您可以引用帖子，所以您不能只创建新帖子并通过关闭旧帖子来引用旧帖子吗？我认为这是Roslyn上的工作人员这样做的方式，然后他们发表了一篇文章，概述了即将发布的版本的所有功能，但是尽管如此，我还是同意您的观点，固定的评论可能非常有用。

eyalsk 于 2016-05-17

👍1

我们一直在努力在这个里程碑中实现选项卡和编辑器组的设计，并将在下一个里程碑中继续这样做

感谢最近这两天参与UX研究的所有人。我们收到了您的宝贵反馈，这些反馈已帮助我们改善了体验：

重新设计溢出图标
提供用于选择是固定还是预览快速打开文件的设置
添加命令以将预览文件转换为固定文件

stevencl 于 2016-05-27

👍9

抱歉，如果我错过了，但是如何启用标签页？它们是否在最新的内部版本中可用（如我所知），但那里没有任何选项卡。我还仍然在资源管理器中看到“工作文件”，但似乎应该用＃6536中所述的“打开的编辑器”代替。

lllopo 于 2016-06-01

@lllopo它们尚不可用。堆栈/开放式编辑器已合并到v1.3.0中，并将在下周的每日构建可用时在Insiders中提供。

Tyriar 于 2016-06-01

👍9 🎉6 ❤1

+1

jan-zajic 于 2016-06-02

👎5

+1

krisquigley 于 2016-06-02

👎4

👎

nmoore2 于 2016-06-03

👎8

这是怎么回事，为什么您拒绝为我们提供使用选项卡的选项？ 😕
很多人都喜欢包括我在内的标签页，给我们该死的选项PERIOD！

aminroosta 于 2016-06-05

👎7

@aminroosta说真的...你看不懂吗？你瞎了吗

有趣的是，您正在询问这里发生了什么……然后继续并假设他们实际上拒绝了它，或者以他们自己的话说“抵抗”，而实际上他们确认选项卡即将来临并正在实施它！

这个世界上有些人！难以置信的！

eyalsk 于 2016-06-05

👍4

@eyalsk
我花了25分钟阅读前20到30条评论。
我很累，只留下了一条评论，这似乎对我来说是个错误。

对于那个很抱歉。

aminroosta 于 2016-06-05

👍1

我们不能责怪微软研发部门尝试创新。标签系统有缺点。

UI设计就像所有形式的设计一样。 90％的用户等待用户等待，10％的用户尝试创造新的革命性且用户友好的系统。

如今，所有在新文本编辑器中必须具备的用户友好系统都已经过试验和争议。

Guema 于 2016-06-05

@aminroosta我会给您一个提示，当您阅读长篇文章时，请阅读原始文章，然后要花最新一分钟左右的时间从底部滚动到顶部，以获取最新的更新。

eyalsk 于 2016-06-05

👍1

这是一个很好的建议，因为这很长。

在2016年6月5日，星期日，上午10:42 Eyal Solnik [email protected]
写道：

@aminroosta https://github.com/aminroosta我会给你一个小费
您正在阅读一长篇文章，请阅读原始文章，然后获取
最新更新要花一分钟左右的时间才能从底部滚动到顶部。
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/Microsoft/vscode/issues/224#issuecomment -223826495，
或使线程静音
https://github.com/notifications/unsubscribe/AAInRHy6TDR-opr-8ZKmW-lRUgZDOP21ks5qIwqIgaJpZM4GljE8
。

glennblock 于 2016-06-05

我个人喜欢Ctrl + Tab方法。根据我的个人经验，如果同时打开10个以上的选项卡，它们会很快变得混乱。我会说删除“工作文件”或至少保留它为选项。我不使用它，这给我增加了困惑。谢谢，我将从这里开始使用Ctrl + Tab！

adred 于 2016-06-06

就我所知， Working files （现在称为Open editors ）和Tabs都是可选的。

eyalsk 于 2016-06-06

@bpasero

您可以_please_锁定该线程并打开一个新线程，并复制该线程的重要部分吗？每天仍有一些听不懂的人发表评论（应该告诉你它太长了），并一遍又一遍地问同样的问题，一旦标签发布发布到公共建筑中，我们将在此线程中看到更多垃圾邮件。

我想了解与制表符相关的最新信息，而该线程当前是执行此操作的地方，但是每天多次收到相同评论的垃圾邮件是非常烦人的事情。

抱歉并表示歉意。

anyong 于 2016-06-06

👍3

+1太多了。

在2016年6月6日星期一上午7点16分，“ anyong” [email protected]写道：

@bpasero

您可以_please_锁定该线程并打开一个新线程，并复制该线程的重要部分吗？每天仍有一些听不懂的人发表评论（应该告诉你它太长了），并一遍又一遍地问同样的问题，一旦标签发布发布到公共建筑中，我们将在此线程中看到更多垃圾邮件。

我想了解与制表符相关的最新信息，而该线程当前是执行此操作的地方，但是每天多次收到相同评论的垃圾邮件是非常烦人的事情。

抱歉并表示歉意。

您收到此邮件是因为您发表了评论。
直接回复此电子邮件或在GitHub上查看：
https://github.com/Microsoft/vscode/issues/224#issuecomment -223906131

mikewl 于 2016-06-06

只是对更新文本的评论@ https://code.visualstudio.com/updates#_workbench

文本对我来说还不清楚，实际上我以为更新的堆栈已经在这里了（以后会出现选项卡）。更新后，我没有看到更新后的堆栈，不得不重新阅读几次。

对我来说，它表示选项卡将需要更多的迭代（因此_this_ update中没有选项卡），但是在5月，您在如何管理编辑器堆栈方面取得了很大的进步（因此，尽管没有选项卡，但此更新中的更新堆栈_are_吗？）并且June发行分支还有更多工作要做（进一步改善堆栈？）。

因此，对于任何可能像我一样感到困惑的人..好像更新的堆栈实际上不在此更新中。我想这只是即将到来的选项卡和堆栈的预览。

RyanEwen 于 2016-06-06

👍19

我同意@RyanEwen。我真的很喜欢开放式开发和交流的数量，但是这些声明是正式的“发行说明”的一部分，确实令人困惑。

也许可以将其分为实际的发行说明，以及“我们现在正在做什么”之类的东西。

remcoros 于 2016-06-07

👍3

在路线图中将这个问题联系起来并不是一个好主意，因为如果您从头开始阅读它，就不会对当前状态有一个清晰的了解（比里程碑更重要）。仍有工作要做，但当前状态还可以：+1：

javmonisu 于 2016-06-07

是的，他们应该总结问题，然后链接到这些摘要，以便人们在讨论后可以了解当前计划。

链接到讨论很不好，因为讨论往往很冗长，并且人们几乎不阅读所有内容就无法理解这个想法，但不知道，否则他们不可能这样做。

eyalsk 于 2016-06-07

当我开始阅读1.2的发行说明时，我寻找的第一件事是_The Tab Feature_。我赞赏他们将当前状态放在那里。但是我也很困惑。起初，我以为它降落了，但没有意识到，但是取得了很多进步。在那种情况下，确实感觉该项目应该在发行说明的底部，并带有讨论链接或里程碑（它们都证明了该功能的进展）以及一个小注释，例如_“ Tabs实施方面的进展”。

不管这件小事。发行上的出色表现。 VS Code是一款出色的产品，具有惊人的开发周期。

andradei 于 2016-06-07

👍3

VSCode刚刚更新为1.3.0-insider。最近的文件似乎不见了。现在有办法吗？

JoshClose 于 2016-06-07

感谢您对发行说明的反馈，对于造成混淆的情况，我们深表歉意。我已经对该文档进行了修改，以使该工作不处于“稳定”状态，但是您可以预览Insiders Release中的标签工作。

在结尾处有一个部分讨论完成的工作，而不是在稳定的版本中进行讨论是一个好主意，如果我们还有更多适合该工作的工作将在下个月进行。

chrisdias 于 2016-06-07

@JoshClose，请

chrisdias 于 2016-06-07

👍3

首先，让我再一次感谢大家对您对标签的想法，喜欢和不喜欢的时间。我们在该主题中看到的反馈（正面和负面）确实表明人们对VS Code的未来充满热情。

我想每个人都可以同意我们已经用尽了这个问题的实用性，因此我将锁定对话。在我们提供选项卡/无选项卡的选项之前，我们将一直保留此问题，我们计划在2016年6月迭代结束之前这样做。

在VS Code团队_may_发布此问题的更新时，您应该期望我们会为其他标签设计或讨论创建新问题。我们将使用tabs标签标记问题，以使其更易于查询。您也可以打开新选项卡上的特定问题，我们期待着您对特定问题的反馈，因为我们将共同努力，打造最佳体验。

再次感谢，现在去安装Insiders Release ！

chrisdias 于 2016-06-08

https://github.com/Microsoft/vscode/issues/6605记录了所有添加或更改的命令标识符以用于键绑定。由于堆栈模型对VS Code的UI进行了很大的更改，因此我们决定重新访问与编辑器或组有关的所有命令。

bpasero 于 2016-06-09

我们很高兴地宣布，您现在可以在每晚的内部人员内部版本（http://code.visualstudio.com/Download#insiders）中启用选项卡。相关设置为workbench.editor.showTabs 。有关编辑器堆栈，预览编辑器和选项卡的概念的更多详细信息，请参考我们的发行说明。

直到本月底（可能还有更长时间），该领域仍计划进行一些工作，因此我们很高兴收集内部人员的反馈。在使用标签页时发现问题时可以随时打开。

谢谢！

bpasero 于 2016-06-19

正如@bpasero提到的那样，您现在可以在我们的每晚内部人员内部版本中启用选项卡。

如果您尝试过此操作，并且可以花30分钟分享您的反馈，请在此处注册聊天： https :

不幸的是，我只能在下周星期一和星期二的白天（我在苏格兰爱丁堡）提供时间段。

stevencl 于 2016-06-21

tl; dr; VS Code内部人员中的启用选项卡使用workbench.editor.showTabs: true构建

我们将在本周通过常规的残局测试来结束6月的里程碑。选项卡位于测试计划（https://github.com/Microsoft/vscode/issues/7854）上，并将在一周内得到一些报道。我们仍然希望对6月的标签进行修复，并可能根据6月的反馈进行完善。虽然大部分工作都已完成，所以我将解决此问题。

从此工作项的描述中， @ TurkeyMan要求具有选项卡，以及将选项卡移出工作台以在新窗口中打开的方法。我将后者提取到https://github.com/Microsoft/vscode/issues/8171中，因为它与我们所做的选项卡工作无关。

尝试时，请继续在标签上提交问题，以备不时之需。感谢您帮助测试内部人员的建立！

bpasero 于 2016-06-27

Vscode: 正确的标签用于打开文件

最有用的评论

视觉设计

预览标签

溢出

导航标签

工作档案

所有411条评论

模型1文件（标签）| 查看1个文件（标签）| 控制器1文件（选项卡）

模型2文件（标签）| 查看2个文件（标签）| 控制器2文件（选项卡）

视觉设计

预览标签

溢出

导航标签

工作档案

相关问题