Vscode: 集成终端的标签

创建于 2016-08-15  ·  191评论  ·  资料来源: microsoft/vscode

功能要求。

默认终端

image

但是可能更有用...

terminals2
terminals1

feature-request integrated-terminal layout ux

最有用的评论

我希望这会因为需求而很快引起注意,我也很想要它。 就像@jaxspades提到的那样,它也在路线图上。

所有191条评论

选项卡最初被考虑,但是被团队广泛批评,因为它可能导致底部带有选项卡的混乱,并使vscode显得“轻巧”。 如果我没有focusNextfocusPrevious终端的键盘绑定,我会因为缺少选项卡而感到非常沮丧,因为下拉菜单很难使用。

还考虑了拆分视图,然后取消优先级,因为像tmux类的应用程序可以在集成终端中运行以实现类似的结果,因此,我从此出发,并非常希望能够拆分终端。 我不是特别想学习tmux的键盘绑定,而我的工作流程的一部分是让多个终端同时显示。 通常是我监视错误的监视命令以及手动构建或启动命令。 让我们跟踪在#7504中拆分终端

@stevencl @ bgashler1请再次权衡标签,记住我找不到终端的focusNextfocusPrevious操作的合理默认键绑定(我绑定ctrl + shift + j / k)。

我们需要在此问题的上下文中考虑此问题: https :

我真的很警惕标签设计中的标签。 我们最终将只使用所有可用空间来显示标签:-)

只是在这里大声思考,如果允许拆分终端,我们真的需要显示选项卡吗? 如果我们只需要公开一些操作即可拆分和折叠终端,而不必显示实际选项卡就足够了吗?

也许我可以看到自己在选项卡/多个终端上使用了2-3个拆分终端。 管理拆分终端和选项卡终端会变得非常混乱,由于缺少键绑定,可能几乎无法使用。

如果我们打开了拆分端子的门,那么拆分一个终端和一个调试代表意味着什么? 相同的UX交互吗?

@bpasero通过拆分我的意思是在侧面创建一个新的终端,所以是的。

为了简化交互,可以设置一个始终使用下拉菜单或拆分端子的设置。 这样,所有现有命令仍然可以正常工作,您只需选择随时显示1个或所有终端即可。

我对引入标签和拆分到终端的担心是,它看起来像一个编辑组。 我不想让用户失望,因为他们不能将编辑器拖入终端或将终端拖入编辑器组。*此外,引入此方法可能在窗口管理中有些滑坡,例如为什么我们甚至有一个特殊的水平首先是这样的面板。 为什么不让终端生活在任何地方,而不是在自定义UI中复制这么多的功能呢?

*也许我们可以通过在x轴上锁定拖动和/或在尝试将其拖到某个区域之外时使用禁用光标来告知他们限制,但是很难避免人们期望它起作用。

当我们引入编辑器组的水平拆分时,我们施加的约束之一是编辑器组只能水平拆分或垂直拆分。 因此,对于用户来说,在垂直编辑器组下面放置一个看起来与水平编辑器组极为相似(但行为方式不完全相同)的面板可能是非常奇怪的。

我们应该在周三的UX同​​步期间讨论更多有关此的内容。 我上次没有显示的一些与水平布局有关的设计与此有关

将终端与编辑器选项卡对齐以使终端自动反映编辑器文件的语言的选项呢?

打开终端将自动为活动的(当前选择的)编辑器语言加载预配置的外壳程序。 settings.json文件中必须支持多个终端外壳。

编辑器的拆分方式无关紧要-终端始终显示所选(活动)编辑器的外壳。 这很简单明了。 使用此方法,无需拆分终端,也无需使用标签式终端。 终端将继续像现在一样显示。

如果该语言有多个外壳程序,或者您要为一个编辑器选项卡运行诸如节点外壳程序和git外壳程序之类的配置,则可以在一个窗格中选择这些外壳程序。 这有点像带选项卡的终端,只是它们没有显示为硬选项卡,这表示子上下文。 这并不像标签那样“感觉”到实质。 它们的上下文在当前所选编辑器的终端窗格中。

位于终端右上方的一个简单的超文本字符串(每个shell一个)将显示当前选择的编辑器打开的shell(已实例化)。 用户既可以单击超文本字符串(可能表示节点)来选择它,也可以使用键绑定来循环浏览。 这些将替换现有的下拉菜单,+和垃圾桶。 外壳可能用小写字母表示。

可以显示一个简单的超文本字符串,也可以仅显示一个图标-尽管字符串可能更好。 这将替换当前在VSCode中使用的繁琐的下拉列表,并一目了然地显示shell。

当您将焦点从当前编辑器切换到使用另一种语言(例如Ruby)的编辑器时,终端将在终端中显示IRB实例。 如果用户要打开当前外壳程序的另一个实例,他们可能只需将鼠标悬停在该外壳程序的超文本上,然后单击将出现的+ 。 如果超文本字符串很短(例如node,irb,cmd,ps),则可以在用于创建新实例的字符串旁边创建另一个字符串。 字符串会分开移动以腾出空间,但不会杂乱无章,因为可以设置一个限制(谁将对一个编辑器打开三个以上的shell?)。

将鼠标悬停在外壳上也可以显示一个峰值,该峰值显示该字符串的外壳内容。 但是,如果用户使用键绑定来切换/循环,则可能更容易进行检查。

如果要为用户提供添加与编辑器无关的外壳的选项(例如git shell),则单击+可以显示在settings.json文件中注册的外壳菜单。 的-这将出现在悬停相邻的超文本字符串将,当然,不显示任何选项。 它将关闭当前的shell实例。

如果用户想要更改外壳程序类型,则可以退出外壳程序(以退回到默认值),然后通过键入外壳程序名称启动新的外壳程序。 表示外壳的超文本字符串将更改以反映新的外壳。

对于git shell,为用户提供选项以指定git shell将始终使用编辑器的语言shell打开是合乎逻辑的,以便git位于该文件位置的上下文中。 如果从同一git位置打开多个文件,则所有编辑器中的所有git shell实例将反映最新的更新或命令。

settings.json文件可能会要求用户针对每个terminal.internal.shell输入特定的语言扩展名(.js,.cs,.rb)。 条目,以便与文件进行逻辑匹配。 可以为settings.json中未指定的任何文件类型配置默认外壳。

只要打开该编辑器,为该编辑器加载的shell实例就会持续存在。 一旦关闭了编辑器(文件),关联的终端外壳也将关闭。

我相信这是一个简单的实现,它也将使VSCode比现在更强大,同时非常直观。 当用户在语言编辑器之间切换上下文时,他们不必考虑终端。 终端将始终显示最后一次用于所选编辑器的外壳程序和代码,包括关联的历史记录等。

@ nick-walt虽然对某些人可能更直观,但对其他人则完全不直观。 这可能会导致人们有​​些迷失方向,并想知道他们的外壳去了哪里。 我的要求是同时显示2个外壳; 一个用于监视错误的监视任务,另一个用于启动任务,git,build等。

之前已经出现了多个终端配置,我不确定是否值得增加额外的复杂性,尽管在大多数情况下,您可以仅在其他外壳中运行该外壳(在cmd中打开powershell,ruby,node等)。

@蒂里亚尔
这些是令人关注的问题,但我认为,考虑这些问题时,可以很轻松地解决它们。

避免迷失方向
在默认状态下,在未配置的新安装中,终端可以以熟悉的方式运行。 这样可以避免因意外行为而迷失方向。

分割终端
拆分终端窗格不会更改模型。 这只是一次在终端窗格中查看多个外壳的方法。 可以将窗格拖出主窗口,然后在另一台监视器上全屏显示。 然后,用户可以告诉终端在垂直或水平方向上在打开的外壳之间自动均匀地拆分。 一个终端,多个外壳-全部与当前选定的编辑器关联。

观看
如果我们不想在切换到另一个编辑器时看不到正在观看的Shell实例,那么也许可以显示可配置行数的监视功能可以解决此问题。 如果发生错误,这也可以显示为图标,以防用户由于快速滚动而错过它。 这已在VSCode的“错误”窗格中完成。 观察者面板只能显示,将鼠标悬停在它上面可以显示更大的样本。

精致无负担
借助上下文终端,您可以在所有编辑器中拥有多个shell,而不会感到不知所措或费力。 给定正确的模型,UI / UX成员可以使其优雅地工作。

我认为您的担忧可以得到充分解决。

这取决于要使用哪个终端(假定)。 如果将其用于运行某个命令,则几乎不需要以任何方式使用多个终端。

如果要用于同时运行多个后台任务(例如服务,构建,监视,测试等),则需要多个终端。

因此,在这种情况下,可以快速概览哪些终端已打开以及它们正在运行(大概处于运行状态)。 我不确定如果没有named / maked选项卡怎么办。

还需要拆分视图,因为在宽屏上至少有一个终端可以使用。

另一个问题是与任务运行器的协作使用。 当前仅用于一次运行一个任务。 但这https://github.com/Microsoft/vscode/issues/981假定它将支持多个后台任务-因此,对于多个终端,这就像一个(我不会说有冲突的)目的。

Jetbrains Webstorm currenlty具有这样的功能-它可以运行多个任务(通过grunt / gulp / npm定义)和多个终端(带有命名的选项卡)。 您也可以在此处使用拆分视图,在该视图的一侧可以看到正在运行的任务,而在另一侧可以看到终端。 (附上屏幕)

image

@whitecolor

好的,因此,如果我们列出所有方案及其共性,那么应该有可能将所需的功能提炼成优雅的样式,从而可以解决各种用途-而不会使VSCode变得过于沉重。

许多标签都没有疲劳
在终端绑定到编辑器上下文的情况下,可用性断开连接(例如哪个选项卡与哪个编辑器相关联)的问题将使用“软选项卡”(又名在终端/编辑器上下文中命名外壳的超文本字符串)来实现还有更多选项卡,而不会导致用户去寻找选项卡,并且避免上下文/关联疲劳引起他们的头疼。

命名壳
通过一个简单的超文本字符串在终端窗格中显示外壳实例名称的想法,就可以进行替代性的创建和命名。 因此,用户在settings.json中配置了一个外壳程序,可能是'cmd'。

一旦它们进入外壳,它们就可以跳入另一个外壳,例如'powershell'或'bash',并且终端标头中名为'cmd'的超文本字符串可以更改以反映用户跳转到的外壳。

或者,用户可以使用启动面板“ cmd”外壳中创建的新命令来创建其他外壳实例。”。

这个想法是在UI中暗示一个事实,即命名的shell不是取消关联的选项卡,而是父编辑器中的shell。 我使用术语“选项卡”来表示与其他任何事物分离的独立的,独立的外壳。 这可能是一种模式,其中硬选项卡是全局的,而软选项卡在编辑器上下文中。

如果包含硬选项卡/软选项卡模式,则硬选项卡可能具有硬边界,就像显示编辑器的选项卡一样。 名称的行为与软标签相同。

关键是维护已建立的UI / UX模型。 我们都看到过很多实例,其中单个应用程序中的不同UI实施破坏了模型。 实际上,微软擅长于此(最近,苹果也是如此)。 这是“委员会设计”的经典案例。
已建立

简单的单外壳用户
但是,如果用户想简化运行并且只使用一个终端/外壳,那么就没有办法实现这一点,重要的是,配置很简单。 这只是考虑矩阵中的另一个使用场景。

如果要添加选项卡,我想有一个配置选项来禁用它们/强制集成终端的单个实例。 如果我需要这样的_advanced_功能,通常会使用自己选择的(外部)终端。

我也考虑终端分割(更高级的分割)之类的东西,因此所有运行中的(可能超过两个)重要的终端都会输出,甚至在一部分人眼前。

如何在文件选项卡的同一位置显示终端选项卡?
它不会污染UI,并且不会丢失任何功能。

@cescoferraro我喜欢这个主意。 但是,VS Code还应该支持垂直拆分的标签视图,而不仅是水平的。 否则,在不浪费空间的情况下看多个终端将根本不符合条件。

@Phisherman不要误会我的意思,我喜欢拆分终端。
我在具有大屏幕和大量内存设置的Intellij上经常使用它。
无论决定是什么,如果占用大量内存以保持VSCode尽可能快,则它应该是可插入的。

我写了一个扩展程序,您可以选择npm / gulp任务,它将启动终端(带有任务名称)并在其中运行,还将在状态栏上放置一个项目,您可以随时单击它对正在运行的进程状态进行基本跟踪。
image

只是为了显示可能的“标签”位置,它们可以在末端的底部。

@whitecolor :open_mouth:这是使用新的终端API吗? 棒极了!

@Tyriar是的,您正在研究的那个:wink:

@whitecolor所述,WebStorm确实具有用于终端的选项卡,这可以提高IDE的可访问性。 除了此WebStorm,您还可以更改选项卡的名称,这又可以帮助您直观地识别要开始的内容。

WebStorm不能做的事情是,它不保存打开的终端选项卡的数量。
开发时,通常需要相同的选项卡(服务器,监视程序,后端...)。 如果可以保存选项卡的数量及其名称,那就太好了。

@whitecolor仔细考虑一下之后,以这种方式在实现终端选项卡中使用当前API会遇到一些问题,假设您要公开扩展“创建新终端”命令,而该命令要覆盖默认命令。 如果您有兴趣构建这样的扩展程序,那么应该跟踪以下问题:

  • 重新启动vscode时,将创建一个标准终端,您无法在该终端上附加状态栏项目
  • 当用户处置终端时,扩展名不知道,因此状态栏项目将至少停留在周围,直到再次单击为止#10925
  • (错误)部署终端将显示面板#11275
  • 同样在v1.6.0中可能会默认隐藏终端,因此您需要在创建终端后立即调用Terminal.show

@Tyriar感谢您的分享,将回答您的清单:

1)是的,它不是那么重要,我的扩展程序实际上添加了一个命令“ Open new terminal”,并允许打开新的命名终端,我通常只是关闭标准,并使用创建的终端,但是如果可以访问面板中所有现有的终端。
2)是的扩展名不知道终端状态,但是我通过PID跟踪terminal._id的子进程,因此我知道终端何时被用户处置(子进程为0)。 因此,我以后问不要取消此进程ID,不确定是否需要将其公开)。 因此,我什至跟踪正在运行的子进程的数量,如果减少了子进程的数量,这可能意味着出现了错误或任务已完成运行,那么我向该终端展示了这一点,非常有用。
3)所以我不使用当前处置。

真正缺乏的是对过程输出的访问权限,这将允许进行更有用的分析(例如,跟踪某些错误/异常输出)并将终端显示给用户。

扩展程序实际上已经准备好发布了,可能几天之后就会发布。

@whitecolor当前只能访问通过API创建的终端,尽管如此,这确实是一个令人信服的案例。

偷偷摸摸地偷看terminal._id :wink:它可能不会很快改变,但是一旦添加了您可以听的事件,您就应该利用它,因为它将成为官方的稳定API。 在#11422中将探讨子进程的跟踪和输出(您可以按照与该主题相关的问题进行一些讨论)。

使用命名的终端命令,您还可以提供#10023的解决方法:smiley:

做得好,期待尝试!

@whitecolor仅供参考,所以我撒谎了,在v1.6中terminal._id可能会更改为一些随机ID,而不是PID。 我正处于一个巨大的重构之中,目的是将终端面板与更多进程分开(这样它们就可以在没有面板#11275的情况下存在),而且我认为我不能将其保留在那里。

@whitecolor您可以在明天的内部人士中试用window.onDidCloseTerminal (#10925)。 它应该比跟踪PID更容易。

我很想像InteliJ一样看它。 在此之前,我将其添加为个人密码:

[
    {
        "key": "ctrl+pageup",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },{
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }
] 

在选项卡之间导航时使用相同的键盘快捷键,但是如果光标集中在终端上,则在终端之间切换。

终端选项卡上的拆分视图非常有用;

我目前正在尝试对服务器实例进行概念验证,并通过另一个控制台终端执行请求。

有什么进展吗?

@MeirionHughes
tmux可能是一个解决方案,但它在VSCode集成终端(最后在Windows中)中运行不佳。

@MeirionHughes这是该功能的问题https://github.com/Microsoft/vscode/issues/7504。 到目前为止,没有任何进展,上一次我努力争取时,我却被团队退缩了。 在这个问题上越多的:+1:越好。

@Tyriar,您可以说这个问题也在要求拆分,如在第三个图像中明确显示的那样。 再加上这个问题有112👍:)

@MeirionHughes第一条评论(我的)说:

让我们跟踪在#7504中拆分终端

这样做的原因是,对于两个不同功能的讨论不会彼此产生干扰。

哦,伙计们,请帮忙,因为它确实是非常重要的UI功能,有时它会使crz下拉菜单切换控制台,非常感谢;)

cycle terminal键盘绑定+1。

@whitecolor _darn!_我以为集成终端中的tmux是我自己的聪明解决方法,但您击败了我。 对我来说工作正常(没有mouse mode ),但是窗格工作正常:

screen shot 2017-02-06 at 2 12 51 pm

鼠标模式对我使用tmux正常工作。

无论如何,我认为这是一个很好的补充

我认为这将非常有用。 但是我不认为它应该仅限于终端,还应包括“问题”,“输出”等选项卡,因此您可以在一个视图中打开“终端”,“问题”和一个编辑器。

我还想在按键绑定上仅+1以在终端之间循环。 我讨厌不得不使用鼠标单击那个小的下拉菜单,特别是在带有触控板的笔记本电脑上。

给我一个按键绑定以在终端之间循环,我想我可以不用拆分/制表符

@ psimoneau22这是我使用的键绑定:

{ "key": "ctrl+shift+j",    "command": "workbench.action.terminal.focusNext" },
{ "key": "ctrl+shift+k",    "command": "workbench.action.terminal.focusPrevious" },

我们将尽快进行拆分。

我不敢相信这个编辑器会变得多么出色和强大。 这将是一个非常强大的功能,它仅用于打开vscode,而在编码过程中仅此而已。

TL; DR; 用几个小时来拿起tmux。

我对终端中的tmux感到满意(鼠标模式就像一个符咒一样)。 我花了一天的时间学习。 我之前玩过几次,但是昨天我像老板一样花了很多时间来设置它。 我只是在iTerm中执行tmux -CC -启动终端窗口。 然后在vscode终端中执行tmux a挂接到该会话-这是我获得的持久性终端会话,因此在重新启动vscode时,我总是可以按会话返回(更新Vscode,安装扩展名)。 对我来说,这比在终端中具有制表符或拆分符要好得多。 请保持Vscode亮。 Atom是一个值得学习的课程(我从中吸取了教训)。 TMUX FTW :)

同样的方法在Mac / cygwin / windows中也适用于我,并且在运行Vscode的任何地方都应该可以使用。

TL; DR;

最好有集成终端的标签,而不是下拉菜单。 将来有机会看到此功能吗?

考虑快捷键ctrl + shift + `ctrl + `我相信这些设置更有意义。

  {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious"
    }

@leocaseiro @Tyriar @ psimoneau22除非您使用的是Mac,否则应在ctrl + shift + leftctrl添加'when'选项shift + right用于在编辑器中选择文本块。

    {
        "key": "ctrl+shift+j",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+k",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

要么

    {
        "key": "ctrl+shift+right",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "ctrl+shift+left",
        "command": "workbench.action.terminal.focusPrevious",
         "when": "terminalFocus"
    }

这是我的2ct镜头,非常适合该功能(对不起,如果已经提到了一些要点)

用例
我在第一种情况下使用多个终端的原因通常是:

  • 我需要在两个目录中并行工作,并且不想一直将cd向前和向后移动
  • 我需要使用两个不同的终端(例如bash vs powershel vs cmd或local vs remote / ssh)
  • 我想同时监视两个不同程序的输出

请注意,只有在第三种情况下,才需要终端的拆分视图。 在大多数其他情况下,我更希望一个终端使用尽可能多的空间。

用户界面
为什么不扩展当前选项卡(例如,Debugging,Ouput,Terminal ...),并允许附加的“ Terminal1,Terminal2,Terminal3...。”

标签页与下拉列表

  • 您会看到所有可用的标签
  • (对我而言)更容易记住,如果终端由不同的视觉位置表示(例如,第三个选项卡),那么哪个终端将达到哪个目的

tl; dr

我非常同意@MikeGitb ,我总是一次使用多个终端。 当前VS Code中终端的下拉列表很难看到打开的选项卡。 拥有用于集成终端的选项卡真的很棒。 谢谢。

一个疯狂的主意:为什么不赋予终端与常规编辑器选项卡相同的状态? 如果要同时看到多条线,将特别方便。

一个疯狂的主意

vim / neovim的工作原理并不疯狂。

vim / neovim的工作原理并不疯狂。

与许多其他IDE一样;)。

抱歉,该介绍实际上具有讽刺意味。

@Tyriar是否具有允许在代码旁垂直平移终端的功能,还是不允许这样做?

为终端提供与编辑器选项卡相同的状态将非常高兴-ComEmu和HyperTerminal都有严重的问题阻止了它们的当前使用(ConEmu存在无法解决的对比问题,因为维护者希望保持XP支持,HyperTerminal无法做到在Powershell和其他基础知识中按Ctrl + C)。 将vscode用作可选项卡式终端将是很棒的。

我还一直在观察何时发布集成终端的选项卡式视图,而不是下拉列表。

下拉菜单使用起来有些不舒服。 还有一个以上的开放终端将是巨大的。

对于想在等待制表符支持时尝试tmux的人,我创建了一个要点来启动安装程序。 它默认情况下启用了鼠标支持,并使用简单的绑定来拆分终端。
https://gist.github.com/cybertim/e8b42c8cd8a5bebaa3eb8cec17a2746f

感谢@cybertim ,伟大的文件! 我已经使用过tmux,但是这个文件很方便。

我本人会非常热衷于窗口内不同位置的多个终端的原因是希望它能引领在VSCode中实现类似RStudio / Jupyter Lab的环境的方式。

我个人希望所有内容都成为选项卡,然后提供在垂直和水平方向无限拆分面板的功能。 然后,您还可以提供固定标签的功能,以保留最常用的工具,例如终端,资源管理器和搜索。

较旧的编辑器顶部的长长的工具栏上有保存,撤消,重做按钮-VSCode没有-为什么? 因为可以预期人们会使用键盘。 我们是程序员。 上一个终端,下一个终端都可以绑定到快捷键-使用它。 我说,我们结束了这个问题,继续进行重要的事情。

接下来,还需要标签吗? 窗格? 分裂?

我认为这里的许多人都在要求对VScode来说是过大的功能。 如果他们只是愿意尝试tmux ,就不会要求这样做。 终端给了我们。 使用tmux,它支持制表符。 您最多需要花费几个小时来学习tmux。 有选项卡,窗口,拆分等,如果您需要重新启动VSCode,则只需在重新启动后输入tmux -a ,即可直接回到您的tmux会话中。 开启鼠标模式(配置中仅一行)后,您甚至可以调整窗格的大小,单击选项卡以转到该选项卡。 我反对VSCode中的此功能。 这只会降低性能。 保持VSCode尽可能轻巧-我们不想要另一个Atom。 让tmux做繁重的工作! 正如您在下面看到的那样,我进行了拆分,并且如果您仔细查看底部,我也会有两个选项卡- pythonfish 。 是的,在左下角,我在命令行中使用googler到Google:D

screen shot 2017-05-02 at 5 26 33 pm

@piggyslasher我不知道此功能如何使vscode变慢。
Vscode已经支持具有多个终端实例。 此功能仅用于将下拉选择器更改为希望更好地使用的选项卡功能。

使用此功能,您仍然可以将一个终端实例/选项卡与tmux一起使用,并且不会期望与现在相比性能有所变化。

Vscode是一个多平台编辑器。 告诉人们使用tmux将他们限制在可以使用tmux的环境中。 而且tmux的学习曲线很大,对于像这样的简单功能来说完全是过大了

@piggyslasher的建议很有趣,但是如果您考虑它而不是像“以tmux方式”。

这是我很长一段时间以来一直在考虑的事情。 Tmux具有tabs ,每个tab可以根据需要拆分为尽可能多的panes 。 相反,编辑器具有panes ,然后每个pane可以具有tabs

我更喜欢tmux的方式,因为它就像“终端的这种布局相关,然后我们切换到相关终端的另一个选项卡”

对于诸如React / Angular Development之类的事情,如果您为每个组件打开了JS / HTML / CSS / Test“窗格”,并且为每个正在工作的组件创建了一个“选项卡”,那么我会发现这很有用。

我很想看看是否有可能在插件中执行类似的操作。 Sublime的折纸已经接近,但仍然是“面板上的所有标签”,而不是“面板上的所有标签”。

关于通过选项卡和其他UI机制引入控制台管理的范围和规模存在很多担忧,我只想指出,如果非常明确地定义了要解决的问题,范围和规模的崩溃以及用户期望问题就在眼前。由于解决方案的优雅性而得以缓解。 非常清楚地定义问题,解决方案将更加清晰,并且整个UI和UX中的逻辑更有可能保持一致。 您知道,我们都喜欢使用和创建这种“有效的”感觉。

同样,最好在此线程中提供项目符号或编号列表,列出不同解决方案及其已确定的问题(可能是缩进项目符号/数字)。 这样的话题可以绕圈走,而无需在中央指定位置或最初的帖子中更新这些内容。

在我看来,每个人都同意需要某种形式的控制台管理,而不是当前的形式。 只是解决缩放问题的建议:为用户提供将控制台附加到一个或一组编辑器的选项。 还允许将控制台分开,但无论哪种方式都应由用户定义为默认设置。 将控制台附加到编辑器上下文将有助于减少控制台的过多生成。 此外,它可以让一个编辑器的控制台当选择其他编辑器被隐藏,保持界面的复杂性了。 如果控制台不与编辑器关联,那么事情可能会一发不可收拾,人们会忘记哪个控制台在做什么。

考虑添加用户可配置的设置,该设置可根据文件的名称和位置(或基于文件属性中其他一些更可靠,唯一的标识符)将为编辑器定义的控制台保存在应用中。系统级)。

可以说这种提法正在接近IDE级别,但是创建者已经说过VSCode将IDE的一些优点带入了编辑器领域。 可以引入一种既不沉重也不复杂的控制台解决方案,并且可以带来出色的UX。

如果这没有任何意义,或者我要说的很明显,请告诉我。

@ nick-walt,当您说:

为用户提供将控制台附加到一个或一组编辑器的选项。

您是否建议终端将Shell实例与特定的打开文件相关联?

在我看来,您过于复杂了。 当然,请继续对此进行思考,但是根据我对类似功能的了解,vscode团队希望将此类小功能的影响保持在最小。 因此,我敢打赌他们正在寻找最简单(虽然仍然有效)的解决方案来使人们满意。

这个问题最基本的一点是,下拉菜单不适用于在事物之间进行切换,并且选项卡是一种很好的选择-因此,为什么大多数事物都使用选项卡:编辑器,IDE,浏览器等。我想这里的每个人都同意基本上,任何形式的标签都比下拉列表更可取。

除了我们如何在shell实例之间进行切换的最基本的部分之外,还有一种兴趣在于允许以某种方式同时显示多个实例。 通过底部的终端部分中的窗格,或通过以某种方式使终端选项卡与编辑器选项卡互换,或通过其他解决方案。 这部分比较复杂,在哪种方法上可能没有多少共识。 特别是考虑到@sorahn刚刚指出的有关panes的内容。

就我个人而言,我认为有足够的支持去删除下拉列表(因为它确实不是很好)并用制表符替换它,然后再担心更高级的东西。

一年多以前@ bgashler1说:

我对引入标签和拆分到终端的担心是,它看起来像一个编辑组。 我不想让用户失望,因为他们不能将编辑器拖入终端或将终端拖入编辑器组。*此外,引入此方法可能在窗口管理中有些滑坡,例如为什么我们甚至有一个特殊的水平首先是这样的面板。 为什么不让终端生活在任何地方,而不是在自定义UI中复制这么多的功能呢?

因此,也许此时最好考虑与编辑器选项卡明显不同的选项卡,以指示它们不能与编辑器选项卡互换,以避免混淆?

我同意,选项卡是选择不同控制台的不错的解决方案。

我认为启用控制台与编辑器关联功能的方法只是通过更改用户设置。 启用后,在选择编辑器时打开控制台可以创建关联。 就如此容易。

UI最有可能是,当在应用程序顶部选择了新的编辑器(文件)时,随着编辑器的更改,底部的控制台选项卡也会随之更改。 非常简单直观。

我认为,只有当它们添加基于某些用户上下文将单个控制台与多个编辑器相关联的功能时,它才会变得更加复杂。

  • 目录位置
  • 项目
  • 文件类型(也许当文件位于相同位置时)
  • 编辑器分组(用户定义)
  • 其他一些抽象

这种体验将是,指定的控制台在上下文中选择的任何一个编辑器都保持不变(或者,因为用户希望所有编辑器都可以使用所有控制台,所以保持不变)。

UI的呈现方式是需要使事物富有创造力的地方,以避免感觉复杂,并保持直观,快速和易于使用的感觉。 拥有良好的UI设计,只有创建功能的团队才需要复杂性:)

为了加强控制台选项卡与编辑器的关联,包含控制台选项卡的窗格将清楚地标有编辑器的名称。

并且每个选项卡可以自动显示已加载的控制台类型,例如Git,Node,CMD,Powershell ...,而不是显示Terminal 1,Terminal 2等(如@Perkovec所示)。 这将由应用程序自动生成。

这将允许用户直接选择所需的控制台,而无需在寻找该git或powershell提示的选项卡上进行搜寻。

另一个选项是在应用程序核心中提供基本的选项卡引擎,并允许用户添加其选择的扩展以为控制台管理添加更多功能。 在某些时候,可以将经常使用的功能集成到核心应用中。

如果我对您的理解正确,则严格禁止将终端与编辑器窗口相关联。 大多数时候,我在编辑器选项卡和终端之间没有固定的关系,当我这样做时,肯定不是1:1映射(通常甚至不是1:N)。

@MikeGitb我猜想,取决于用户首选项的权重,可能启用或禁用了默认编辑器与控制台设置的关联。

有些人可能想将两者混为一谈,这取决于他们在做什么以及所使用的控制台。 这只是创建者必须解决的UI / UX问题的改进。 与任何UI / UX挑战相同。

上下文编辑器/控制台UX的用例将是:

  • 没有上下文(没有与任何特定编辑器关联的控制台)
  • 混合上下文(某些控制台关联,有些不关联)
  • 所有上下文(与编辑器关联的所有控制台)

顺便说一句,我建议将控制台与编辑器关联,以最大程度地减少控制台选项卡的扩散(以及不必要的混乱/开销),这是少数人表达的关注。 使用上下文编辑器/控制台UX,一旦选择了另一个上下文中的编辑器,关联的控制台很可能会被隐藏。 用户始终仅查看与所选编辑器相关的内容。

和往常一样,UI实现将成就或破坏这种事情。 VSCode团队已经在UI方面做得非常出色,没有理由认为他们无法弄清楚如何实现更复杂的控制台管理体验,而不会使事情变得复杂和繁重。

正如我们以前所经历的那样,以及使用更新软件所经历的越来越多的情况,这很可能使用户暴露于更高程度的复杂性和复杂性,同时使体验更容易且更简单。

只是为了了解您的用例:请问您在终端上执行哪种操作,这些操作绑定到特定文件而不是项目/目录?

我的典型用例是使用git,编译项目,执行二进制文件并查看一些跟踪输出。 所有这些都与当前打开的文件无关,但是我主要将其用于c ++项目或单个文件编辑,因此其他领域可能需要不同的工作流程。

可以肯定的是,几乎每个人都独立于编辑器选项卡使用终端实例。 这样的功能最好作为扩展。

是的,我同意通过扩展来扩展控制台体验。 可能是向这个领域开放以发展的最好方法。

用VScode创建一个控制台引擎供所有人使用是一个有趣的实验。

以下是Cloud9 IDE工作原理的片段:

ezgif-1-a2ab27787f

它似乎有我们许多人想要的东西:任何新选项卡都可以是编辑器或终端,并且任何选项卡都可以水平或垂直移动和拆分。

@plmrry太棒了! 朝着这个方向前进将是一件好事。

@plmrry的问题是我们是否仍将拥有一个非常灵活的窗格系统。 我个人喜欢面板的固定方式,这使终端命令非常清楚会发生什么。 聚焦终端将始终打开一个终端空间并聚焦活动终端。

如果在编辑器选项卡中有多个终端,一些在前台,一些在后台,那么某些终端命令的作用问题就不太清楚,也就不会那么直观。

终端命令可以只针对最后一个集中的命令吗? 几乎与cmd + shift + t定位到上次关闭的标签页相同

@btoo可能就是这样的世界。 但是,这对VS Code的工作方式来说是一个非常根本的改变。

我来自PHPstorm,缺少终端选项卡确实令人沮丧,所有Brainstorm产品都具有终端选项卡,这是非常有用的功能。

确实是一个有用的功能,我要求开发人员添加它,这将使我们在需要同时监视两个以上事物的地方变得更轻松,我真的很喜欢@plmrry

+1
终端中的选项卡比选择更适合UX使用,并且不占用太多空间

+1

这是我仍然使用iterm和cmder分割屏幕的部分原因,因为我一次可以看到多个屏幕。 有意义的是,vscode当前可以一次运行多个,从而增加了同时显示两者的能力(无论是水平拆分还是制表符都不会影响性能)。

如果这将导致性能问题,那么如果我在一个选项卡中运行npm run server并在另一个选项卡中运行mongod(或者有人可能需要运行的多个命令),则vscode也会冻结。

关于此的小更新:我目前正沉迷于使终端易于访问(https://github.com/Microsoft/vscode/issues/8339),之后,我将要研究的下一个主要部分可能是终端拆分(https://github.com/Microsoft/vscode/issues/7504)这是此问题造成的(可能是许多支持此问题的人真正想要的)。 这在路线图上https://github.com/Microsoft/vscode/wiki/Roadmap#terminal

@AnthonyMichaelc不必担心显示多个,在最近的改进之后,该终端非常快。

(分裂)可能是许多反对这个的人真正想要的

@Tyriar我赞成使用标签,因为我想要标签,而不是拆分。 我怀疑其他大多数人也都表示他们投票赞成的意思-垂直或水平窄的终端对我没有帮助。

...我只是通读了所有这些内容,而且我不敢相信我错过了这个主意:

打开新终端后,为什么不将其他标签添加到现有标签栏?
Problems | Output | Debug Console | Terminal 1 | Terminal 2 | Terminal 3 ...
...此外,如果您实际上并没有使用调试器,则调试控制台并不是非常有用。

(很可能有许多人对此表示强烈反对)

我将仅粘贴此...。(本主题的第一篇文章)

除了@ericblade的评论外,请让我同时至少看到2个面板(问题,输出,控制台,终端...)!
例如,在调试服务器时,我希望观察其他服务的输出或构建我的客户端的文件监视程序,而无需始终切换视图,甚至不通过键盘快捷键即可。
我会很乐意欢迎使用分离式终端(同样在Windows上);但是,可在左/中/右面板中放置的灵活选项卡将大大改善vscode的“观察台”,而不会使UI混乱。

@PixelT您引用的帖子中的第一张图片是添加的标签,与标题中所说的完全一样。 也许提交单独的PR并在此处链接以进行拆分?

@mikemaccana,请再次阅读并理解我的信息,因为我发现您不理解它+我没有删除任何内容:]

@PixelT您说得对,我误以为您已删除照片-对不起。 就是说:标题和第一个建议是制表符而不是拆分,单独的拆分问题会很好。

@mikemaccana拆分: https :

我们可以选择具有选项卡,但默认情况下将其关闭吗?

拆分预览已发布在Insiders中,请查看https://github.com/Microsoft/vscode/issues/7504#issuecomment -365683609以获取完整更新。

kapture 2018-02-14 at 9 12 17

我认为这绝对是朝正确方向迈出的一步。 我确信有人会抱怨为什么我不能放15个终端,但是对我来说,这样做会很棒。 如果在类似平均堆栈的东西上工作,我可以为nodemon和mongos等提供一个双终端,然后打开另一对终端以运行ng serve并生成命令。

现在,如果稳定的vscode版本具有此选项,而我一直在等待所有梦想的具有网格布局的其他功能请求将成为真正的哈哈。

旁注:如果我尝试快速来回切换opt / alt + cmd / ctrl,我只注意到了几分钟的使用时间,但焦点似乎在后面。 (也许就是我)

@安东尼·麦克

我确信有人会抱怨为什么我不能放15个终端,但是对我来说,这样做会很棒。

该计划实际上是允许任意数量,但到目前为止,我仅解决了n = 2的问题。

网格布局

我们现在正在积极讨论这个问题,甚至在2月的迭代计划中占有一席之地https://github.com/Microsoft/vscode/issues/43361

旁注:如果我尝试快速来回切换opt / alt + cmd / ctrl,我只注意到了几分钟的使用时间,但焦点似乎在后面。 (也许就是我)

我还没有看到这个,但是我会留意缓慢的情况。

@安东尼·麦克

如果在类似平均堆栈的东西上工作,我可以为nodemon和mongos等提供一个双终端,然后打开另一对终端以运行ng serve并生成命令。

同时拥有多个终端和编辑器非常舒适。 在我的日常生活中,我有第一个用于开发服务器的终端,第二个用于单元测试,有时第三个用于git。

有打开VSC作为终端标签之一archieve这cmder终端为Windows哈克的方式(在这里)我不能等待的Visual Studio代码解决本地人,becouse存在一些问题与快捷键,而在使用VSC和Cmder这条路。

Visual Studio Code + cmder multiple tabs

@Tyriar我所看到的,这是托皮斯关于终端,没有分裂的标签......?

@PixelT显然是相关的。 在此问题中,许多人说过能够同时看到多个终端,这种分裂暂时可以解决,因此他们会发现它很有用。

我不同意-这个主题主要是观察和讨论想要在终端机中使用标签的人,对于拆分终端机,还有另一个主题:https://github.com/Microsoft/vscode/issues/7504,这是您创建的:)

如今,终端选项卡和拆分已成为几乎所有现代IDE的标准。

切换到内部人员版本进行测试,效果惊人,谢谢@Tyriar

终端中的选项卡仍然没有任何反应...😕

@PixelT您是否尝试过具有双终端的内部版本? 根据他们所说的,他们计划进行制造,以便您可以根据需要在该布局中打开尽可能多的终端,但是我相信内部版本当前允许使用以下命令2个:cmd / ctrl + d我相信

@Morkowski我明白你的所作所为。是的,我有一台Windows和一台osx笔记本电脑,所以当我在Windows计算机上时,我确实会使用cmder,当在osx计算机上时,我使用iterm并在网格内创建至少2到3个布局和4,当在平均堆栈应用程序中工作时。

嘿, @ Tyriar的反馈-使用Maximize Panel SizeRestore Panel Size按钮(或键盘快捷键)调整控制台大小时,控制台窗格的宽度被忽略,每个窗格的宽度为重置为相等的数量。

使用鼠标上下调整控制台大小时,会记住宽度。

同样,隐藏或显示左侧栏时会忽略宽度。

最后,添加或删除窗格时会忘记宽度-尽管这是最容易理解的。

希望这可以帮助!

@jamesjryan在您提到的前两个问题的最新内部https://github.com/Microsoft/vscode/issues/45074

同样,隐藏或显示左侧栏时会忽略宽度。

我无法及时更新,请在发现问题时提出。

最后,添加或删除窗格时会忘记宽度-尽管这是最容易理解的。

是的,这是按设计的🙂

有人正在写有关拆分终端的信息,而不是这里的终端标签。 从这张票中获取通知时,我们不希望看到这样的内容:(

7504

@Tyriar更新了-如描述的那样工作,谢谢!

@KillyMXI,它朝着最终目标迈进了一步,即使是目前的形式,也是非常有用的实现。

@isidorn我想知道您是否考虑过我们最初将如何支持这样的事情。 在添加终端之后在终端中添加选项卡时,我需要还原,因为每个人都反对在选项卡中包含选项卡,如果我们将面板标题选项卡设置为类似以下内容,该怎么办:

screen shot 2018-03-06 at 12 22 50 pm

我真的不知道该如何处理有时较大的标题,需要在此处说一下终端以将其与其他标题区分开。 话虽如此,这将是我的典型设置(带有两个选项卡,其中一个选项卡具有拆分),并且最大化显示后,它很容易放在笔记本电脑的屏幕上,即使不隐藏其他面板标题。

我认为最终游戏为用户提供了将终端放置在所需位置的灵活性,但这也许是一个很好的权宜之计?

@jamesjryan我看不到Tyriar的解决方案是朝向标签的进展。 在我看来完全正交。

周围有很多有用的东西,但是它们有适当的位置。 拆分终端的正确位置是另一张票。

最后,我们回到标签。

上面提出了类似的内容,实际上是: https :
用终端列表替换下拉列表时,这是最明显的事情。

我本来想

  • 将终端标签向右对齐;
  • 或在端子之前添加垂直线;
  • 或向右对齐,当它们靠近左侧的项目时显示一条垂直线。

我宁愿避免在每个选项卡上都使用“ Terminal”一词。 这将是足够清楚的。
或者,可以使用“ Terminals:”一词作为一种视觉分隔符。

Problems   Output   Debug Console                  Terminals:  Git   Bash, Bash   +   []   ^

所以这是我希望在这里达到的最终结果:
68747470733a2f2f7261772e67697468756275736572636f6e74656e742e636f6d2f6a736d656368616d2f61746f6d2d7465726d696e616c2d7461622f6d61737465722f64656d6f2e676966

取自https://atom.io/packages/terminal-tab

它简单易懂,并为最终用户提供了灵活的方式来决定他们如何拆分/组织其IDE。

我很困惑。 我们已经可以在底部,右侧,左侧或全屏位置拥有一个终端。

我们已经可以在底部,右侧,左侧或全屏位置拥有一个终端。

我们的确是? 如何在左侧创建终端? 现在,我只能看到底部或右侧。

您不能离开,但仍然,我对这个gif感到困惑。 大声笑

我不确定Atom插件(不能说我用过),但是我假设您可以打开多个终端,它们都将被视为单独的选项卡。

最重要的是,它们的行为与普通编辑器选项卡的行为相同,它们可以与您拥有代码的位置相同。 Web IDE Cloud9与此非常相似。 您可以根据需要打开任意数量的终端,也可以将它们随意放置在splitscreen + tabs布局内的工作区中。

也许我误会了这种担心,但是基本上,UX设计人员担心不同选项卡之间的混淆。

我将默认隐藏标签栏,并显示1个“标签”。 保持下拉的东西。

然后,一旦启动新终端,如果用户设置了选项,则摆脱下拉菜单并显示选项卡栏。

我想念什么吗?

我认为最好像其他编辑器选项卡一样,将终端设置为选项卡,并让用户决定如何布置窗口。

这就是上面“令人困惑”的gif试图演示的内容。

是的,对不起,如果gif使其更加混乱,但这基本上是我想要达到的前提。

关于UX设计师担心混乱的问题,我认为如果您要打开一个终端,那么您可能知道自己在做什么,并且根本不会造成混乱。

作为一种解决方法,我设置了以下键盘快捷键:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious"
}

它使我可以在终端之间快速切换,而无需使用鼠标和丑陋的选择器。

@vedmant,您也可以优化它,使其仅在终端聚焦时才起作用:

{
  "key": "cmd+right",
  "command": "workbench.action.terminal.focusNext",
  "when": "terminalFocus"
}
{
  "key": "cmd+left",
  "command": "workbench.action.terminal.focusPrevious",
  "when": "terminalFocus"
}

抱歉,如果已经有人提出这样的建议(我只是略过评论),或者我应该把它变成一个新问题。 无论哪种方式,请让我知道。

鉴于问题#14909已取得进展。 我们是否可以选择将终端放到普通标签中,从位置的角度来看,该标签与其他标签一样? 这将为用户提供很大的灵活性,使他们可以查看自己的终端。 现在(或即将推出)在查看和排列常规标签方面具有很大的灵活性,相比之下,终端现在非常受限制。

@Tyriar workbench.action.terminal.focusPrevious似乎不起作用

我还尝试了workbench.action.terminal.focusPreviousPane因为这是Defaults Kebindings使用它的方式,但是它不起作用( workbench.action.terminal.focuNextPane也不起作用)

简而言之:只有workbench.action.terminal.focusNext有效

    {
        "key": "ctrl+pagedown",
        "command": "workbench.action.terminal.focusNext",
        "when": "terminalFocus"
    },
    {
        "key": "cmd+pageup",
        "command": "workbench.action.terminal.focusPrevious",
        "when": "terminalFocus"
    }

VSCode版本

Version 1.24.1
Commit 24f62626b222e9a8313213fb64b10d741a326288
Date 2018-06-13T17:47:35.732Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

操作系统:lubuntu 18.04

测试无扩展

编辑

感谢Tyriar,我写了cmd而不是上面的ctrl

@caub如果需要帮助,您应该创建一个新问题(尽管在Ubuntu 18上,它对我来说一直很好)。

最近,意识到了将终端放置在原地的问题:它使得无法同时看到“问题”选项卡。

我猜您有一个包含多个项目的工作区。 您可以做的是,每个项目有一个终端,并根据编辑器中的焦点文件(及其所属的项目)使相应的终端扩展为焦点。

它不能解决您的特定问题,但可以更轻松地切换和发现问题

我同意终端选择实际上是不实际的,只有数字: 1: bash2: bash ,..最好显示文件夹的基本名称,而不是

通过更多的实践,我意识到此Tabs提案是最好的方法:+1:,目前我仍然独立于VSCode使用我自己的OS终端,因为选择的终端使它不切实际,即使命名更好,也仍然不切实际。

我还认为,如果终端可以作为网格布局的一部分存在,并且从UX角度(在所有位置都可以捕捉到所有内容)的角度出发,它将更有意义。

@mrmckeb同意。 我不确定他们如何处理制表符和拆分,但这是可行的。 Tmux做到了。

我希望我们也可以在文本编辑器窗格中停靠终端,这已经非常灵活了。

我已经看了很长时间了,但仍然希望这个问题能够实现。 我看到类似的问题会定期开放。 希望我可以概括要求什么以及为什么(至少从我的角度来看)。

什么

基本上,我希望可以_可选地_创建一个新终端作为_editor tab_,基本上复制此Atom扩展的行为(自从Atom切换到VSCode以来,我一直很想念它)。 创建新的终端选项卡后,将以与编辑器选项卡相同的方式对待它,并将其放置在编辑器组中。 界面选项卡在UI中的处理方式与编辑器选项卡相同。

端子接线片无需与面板中的端子互换即可启动; 它们可以最初创建为完全独立的实体来收集反馈。

为什么

我实际上住在终端中,以这种方式使用终端选项卡可以解决以下所有问题和用例:

  • 同时查看和使用两个以上的终端。 可以通过布置三个或更多终端来轻松完成,但是我喜欢在编辑器网格上。
  • 通过打开仅包含终端选项卡的VSCode窗口,将VSCode用作我唯一的终端仿真器。
  • 同时打开许多终端,但是我现在不想看。

即使在终端选项卡的世界中,我也会发现与编辑者组不同的面板的存在是有用的,并且我也不主张分配面板。 小组应该放置与我正在使用的_primary content_不同的辅助信息。 关键是,对我而言,终端通常是我正在使用的“一流内容”,而不仅仅是附属内容。 从这个角度来看,终端与编辑一起生活是完全自然的。

@sagebind我认为朝着这个目标迈出的第一步是面板中启用终端选项卡,本质上只是将下拉列表换成了不太可怕的东西。 然后可以通过以下方式建立此基础:

  1. 允许放置在面板更灵活https://github.com/Microsoft/vscode/issues/57029https://github.com/Microsoft/vscode/issues/50984https://github.com/Microsoft/ vscode / issues / 37877https://github.com/Microsoft/vscode/issues/10121
  2. 研究如何允许单个终端与面板“分离”,并在您所谈论的情况下放置在编辑器网格中(在本期中已进行了介绍)。 需要做一些工作才能弄清楚对UX,命令,键绑定和扩展API的影响。

另外, @sagebind ,不确定您是否听说过ConEmu,但这确实

而且,如果您是老派游戏玩家,则可以使用“地震风格”下拉列表(Ctrl +〜)。 因此,我所有的术语都保持隐藏,直到轮到时间了。

我认为此扩展程序显示了如何以干净的方式制作选项卡。

https://marketplace.visualstudio.com/items?itemName=Tyriar.terminal-tabs

@PauloDanielCarneiro那扩展实际上是由VSCode本身的高级开发人员之一(@Tyriar)制作的

我知道这个问题已经很久了,但是这太神奇了

这正是缺少的功能,它阻止所有SysAdmins完全从ISE跳转到VSCode。

作为SysAdmin,我大部分时间都在多台计算机上同时工作。

我使用CTRL + SHIFT + R连接到远程计算机。
这将打开一个新的终端选项卡,该选项卡以我连接的计算机名称命名。
并且每个终端选项卡都链接到下面的一个或几个脚本选项卡。
我使用CTRL + R从脚本选项卡切换到终端选项卡,反之亦然。

同时如此简单,便捷和强大...

tabs

是否正在考虑使用此功能?

不是替代品,但您可以使用cmd-\分割终端

谢谢@ Hum4n01d那还更好,不知道那

@ Hum4n01d就我而言,我可以使用Ctrl+]拆分终端,或者单击图标以拆分终端窗口右上角Kill Terminal选项旁边的终端。

如果我只需要2或3个终端,我认为此功能非常有用(甚至比选项卡更好,因为我不需要从一个选项卡切换到另一个选项卡即可查看终端)。

仅在需要多个终端的情况下,这可能不是解决方案,尽管选项卡也可能不是(本身),而是需要诸如选项卡和浮动窗口之类的东西(https://github.com/Microsoft/vscode / issues 10121)。

我仍然认为,最好的方法是Atom团队采用的方法,使终端与代码选项卡互换。 这样,用户可以以模块化方式创建所需的工作空间。

终端区中的选项卡很酷,但是为什么要花时间允许代码选项卡包装终端实例呢,为什么要花钱呢?

你好。 我去寻找我遇到的一个问题,最后到这里。

我唯一想做的就是将Terminal用作常规编辑器选项卡

我的15英寸笔记本电脑显示屏还不够大,无法把挤在构建输出部分面板中的小终端弄得乱七八糟。它可以很好地进行构建,但不适用于终端。

如果我将面板的大小调整为较大以便可以在此处进行实际工作,则突然间,构建输出弹出窗口变得过大是没有意义的。 而且,如果我将其缩小以便适合构建输出,则无法用于终端工作。 这些UI概念不会混合在一起,并且在选项卡栏中添加进一步的疯狂。

如果我真的不希望终端中执行的工作成为执行任务时在选项卡之间切换的面板的一部分,该怎么办? 还是动态地上下弹出? 这样,每次构建时,我现在都在其他选项卡系统中切换选项

将Panel变成具有竞争习语的并行UI系统是一个坏主意。 各种各样的人正试图通过不良的hack和扩展中的变通办法来做到这一点。 因此,如果Microsoft通过解决此问题来控制局势,那将是一个很好的选择。

@Zyrsha-在这种情况下,为什么要使用VS Code? 听起来,直接使用带有多个选项卡的操作系统附带的实际终端,您会获得更多价值。 诚实的问题/非常困惑的读者。

BTW vscode是我在其中使用终端的第一个也是唯一的IDE。 在我的13英寸笔记本电脑上,它对我来说很好用。对于其他eclipse或webstorm等IDE,我非常高兴使用Awesome WM进行快速切换和窗口排序。

我认为将终端(或任何其他“窗口”)用作常规选项卡的想法很好,并且可以在Eclipse中使用。 但是终端的工作流程略有不同,至少对我而言。 我需要快速切换到“右侧”终端的可能性。 像其他人一样,我使用终端标签
image
不幸的是,由于诸如此类的问题,它并不完美。 而且,我不明白为什么vsc不应该内置一个复杂的终端。

@ shane-smith

操作系统附带的实际终端,带有多个选项卡。

Windows附带的控制台应用程序没有选项卡支持AFAIK。 这样就可以了。 Linux本身并没有“附带”终端仿真器(可能是发行版),您必须选择一个喜欢的终端仿真器。 在这种情况下, @ Zyrsha喜欢的地方似乎是VS Code,如果可以改善的话。

@sagebind

在这种情况下, @ Zyrsha喜欢的地方似乎是VS Code,如果可以改善的话。

哦,我同意-VS Code中的终端很棒。 我对这个问题发表评论,因为我同意它还有一些改进的空间。

我感到困惑的部分是,似乎另一个人想要使用终端来编辑其所有文件-所以我想知道为什么他们实际上不使用内置代码而会使用VS Code。文件编辑器吗? 重新阅读他们的评论,也许我跳到了结论,他们只想在终端中编辑_some_文件,而不是全部。

你好。

我感到困惑的部分是,似乎另一个人想要使用终端来编辑其所有文件-所以我想知道为什么他们实际上不使用内置代码而会使用VS Code。文件编辑器吗? 重新阅读他们的评论,也许我跳到了结论,他们只想在终端中编辑_some_文件,而不是全部。

不,他们只想拥有终端标签,例如编辑器标签,正是我们在Cloud9,Atom和其他一些编辑器(甚至是Vim和Emacs)上拥有的标签。 对于使用Mac或Linux的用户,在窗口的上方具有编辑器,在底部具有一些终端选项卡是很自然的。

甚至Theia-IDE也可以有多个终端选项卡,它基于VSCode的某些部分。

看一下这些屏幕截图,您将了解:

https://discourse-cdn-sjc1.com/business5/uploads/trydiscourse4/optimized/2X/a/a6c21ba006e249a65bb0c4c2ecf94296d6daad20_1_666x500.png

https://lh3.googleusercontent.com/eI50dceQrsPJDhqQmM_QMjd4rkORHRRd_Y3rbnD1M6KYbKulXI72PFC-A0y-SDraVJAXhGTFcg=w640-h400-e365

好吧,让我们暂时忽略一下原因,而专注于如何:

如何实施? 终端在其当前位置是否有架构上的原因?

以一种有效的方式让插件在选项卡中提供终端是否可能?

      Ok, let's ignore the why for a moment and focus on the how:

如何实施? 终端在其当前位置是否有架构上的原因?
以一种有效的方式让插件在选项卡中提供终端是否可能?

在架构方面:

  • VSCode具有链接到一个控制台(PowerShell集成控制台)的许多脚本选项卡,非常适合在一台计算机上测试多个脚本。 但是,即使添加更多终端,所有脚本选项卡仍保持链接到同一PowerShell集成控制台。
    最初,VSCode是由开发人员为开发人员编写的。

  • ISE的构建方式与此相反:您可以打开多个控制台,并且可以在每个控制台上链接多个脚本选项卡(这对于在多台计算机上同时工作非常有用)。
    我们在不同的计算机上同时编写和运行多个脚本
    最初,ISE是为SysAdmins设计的。

不可思议的是,ISE方法(链接到“控制台”选项卡的“脚本”选项卡)也适用于开发人员。
但是当前的VSCode方式(“控制台”选项卡链接到“一个”脚本选项卡)是不适合SysAdmins的。
如果您不希望或无法改变方向(从与控制台链接的脚本到与脚本链接的控制台),至少我们应该能够选择要将每个脚本选项卡链接到哪个控制台选项卡...

我对ISE一无所知,但我绝对希望能够将终端放置在其自己的选项卡或窗口中,而不是永久固定在屏幕底部。 我不喜欢调整高度以从代码文件到终端来回切换。

同样,虽然终端选项卡_does_解决了要激活多个终端的问题,但从UX的角度来看,最好将终端与用于文件的选项卡放在相同的选项卡中。 这样可确保您具有两个用于切换选项卡的标准键绑定,而不是两个标准,以及用于终端选项卡的两个键绑定(不包括用于切换到特定终端选项卡的数字键绑定)。 然后,使用这些选项卡拆分编辑器,将选项卡移动到其他VS Code窗口的工作流程,或者您可以使用这些选项卡进行的其他任何操作,都将是相同的,并会创建标准UX。 从目前的情况来看,您有两个不同的UX工作流程,而从这两个工作中获益不多。

我了解为什么到目前为止可能尚未完成,或者为什么要使用“终端选项卡”作为解决方法,但是在编辑器选项卡/缓冲区/无论以Emacs,Atom等为标准进行的所有操作,终端我也很想在VS Code中看到UX体验。

现在不推荐使用Nuclide,我想切换到VS Code,但是我真的很希望能够读取终端上的所有build输出,这对于VS Code来说非常困难。 为什么需要将终端强制到特定位置,而不将其与其他所有标签/窗口一样对待?

对我来说,主要问题是如果不使用鼠标,我看不到打开了多少个终端。 而且,如果不随意骑车,就无法知道应该朝哪个方向到达特定航站楼。 Tabs是我的第一个想法,但我想还有其他方法可以解决此问题。 例如,您可以选择在资源管理器栏中显示活动终端,突出显示活动终端。

如何实施?

对于linux,我们可以将其作为更通用方法的一种特殊情况来实现:运行用户定义的命令,并为它们提供新标签的X窗口标识符。 然后,我们可以在终端上运行xterm … -into $VSCODE_TAB … ,但也可以非常轻松地集成其他内容。 如果有一个CLI命令按项目目录(默认为运行该命令的工作目录)搜索VSCode实例,然后在该实例中打开一个选项卡,并在stdout上打印X win id,那也很好。和VSCode的$DISPLAY如果不同) 因此,任何外部工具都可以加入VSCode的GUI。

编辑2:我将为此主题打开

不! 选项卡使ui看起来不好....

@ donnisnoni95

不! 选项卡使ui看起来不好....

我非常乐观,很容易停用和/或隐藏它们。

只需将下拉列表转换为按钮,然后将其样式设置为与主编辑器的选项卡相同。

为了清楚起见,我希望这些选项卡可以与所有其他选项卡(例如,源代码选项卡)互换。 就像在Atom中一样。

明确一点,鉴于自2016年以来OP的请求未引起注意,我将采用@andraz@floydnoel的解决方案

@kitsirota已经注意到,并且在今年的路线图中。 他们知道,此问题以及与浮动窗口相关的问题是最需要的两个功能。 我不确定何时开始或完成它,但是@Tyriar可能

我希望这会因为需求而很快引起注意,我也很想要它。 就像@jaxspades提到的那样,它也在路线图上。

从第一天开始,我就开始使用VSCode来等待此窗口和浮动窗口。 目前,我正在使用ConEmu。 当前安装和下拉的终端并不方便。

如果您仍在使用ConEmu,则只需注意一下(当然应该在vscode中添加选项卡),您可能想尝试Windows Terminal。

还在等待这个:)

我只想同时看到“输出”和“调试控制台”。

我不一定需要选项卡,但我想同时查看问题和终端。 但是,如果没有某种标签,可能很难将它们区分开,因此选项卡可能是最好的。 因此,我认为应该删除用于终端的拆分面板,并允许所有面板类型(问题,输出,终端等)使用其他选项卡,尽管我真的看不到需要多少个“输出”或“问题”选项卡,因为数据将是相同的。 因此,也许在添加新选项卡并选择要添加的类型时,如果“问题”已打开,则该选项将显示为灰色,并且无法添加第二个选项卡,并且仅允许“终端”使用多个选项卡。 同样,单击状态栏中的“问题和警告”指示器,在单击它时应会自动打开一个新的“问题”选项卡,如果该选项卡已经打开,则会将其删除。

尽管我真的看不到需要多少个“输出”或“问题”选项卡,因为数据是相同的。

  • 屏幕/键盘/输入焦点到用户的经典1:1映射之外的创意多用户星座图。
  • 单个用户可以在多个屏幕或屏幕区域中分布用于解决问题的工具。 在这种情况下,对每个“问题/输出”面板具有独立的过滤器设置,滚动位置等将很有用。
  • 解决截屏软件中的外来错误/缺失功能。

@Tyriar @jaxspades是1754:+1:和187:heart:还不够吗? 34:火箭:? 应该多少钱?

这还开放吗?

这将有助于众筹吗? 我把钱放在哪里?

@Bessonov我想要终端选项卡,但是我不在Microsoft,所以我没有发言权。 我希望他们作为编辑器,而不是在屏幕底部的那个小窗口中。 因此,1.43版刚刚随搜索编辑器一起提供,所以我希望终端会很快发布。 @Tyriar ,搜索编辑器是否可以帮助我们更接近终端标签/编辑器?

编辑:将链接添加到搜索编辑器问题。

23931

再次,这是在路线图上,它会及时发生。 您无需告诉我,我可能比这里的每个人都想要它,并且众所周知,这是投票率第二高的问题。 但是,它并不像表面上看起来那么琐碎。 我们正在积极投资于灵活的工作台布局:

  • 在面板中搜索
  • 在编辑器中搜索
  • 所有面板和视口视图均可互换

所有这些努力正在最终解决该问题,并极大地阻碍了终端上的工作,例如,我们正在考虑的后一项设计提出了一些非常重要的问题,即终端中的选项卡将如何工作与面板视图相反。

我希望他们作为编辑器,而不是在屏幕底部的那个小窗口中。

很久以前,我试图将这些概念分为几个单独的问题,但是现在这个问题涵盖了几件事。 终端面板中的标签,编辑器中的终端标签和可在两者之间拖动的终端标签。

感谢@Tyriar的更新。 听起来不错-一起解决所有这些问题很有意义。 如果有进行用户测试的机会,请告知我们。

尽管我已经阅读了整个注释,但不确定是否提到了这个想法:
我们(也)不需要终端标签,不是因为外观,而是因为当前所有编辑器标签都链接到同一终端。

当前,如果要在另一个终端中输出编辑器的运行,则必须打开一个新的VS Code控制台。

当您想针对不同的计算机执行不同的编辑器窗格的代码时,能够将编辑器窗格链接到另一个终端的Beeing特别有用。 使用ISE,您可以在同一控制台中执行此操作。
当前使用VS Code,您必须打开与要在其上执行编辑器代码的计算机一样多的控制台。

@蒂里亚尔
除了您的笔记,我还希望能够同时看到“问题”和“终端”窗口。 我希望这也是可能的。
谢谢

我还没听说过@ fullenw1有趣的主意,谢谢!

@ggedde,我们正在积极讨论在UX会议中如何工作。

解决了10121号问题后,这将永远是一个好功能。

接线板需要某种标题。

76528795-bdeb6e00-6447-11ea-9861-65f444e5d867

当您有多个观察者时,不可能知道哪个面板是哪个路径

@IceSentry我确实有问题,@Tyriar说这是该问题的重复。 我认为这是相关的,因为@Tyriar对此表示赞同。.不,我没有读过6年的对话:)

我不知道是否有人指出这一点,但是,如果您想获得有关如何使用“我如何d希望这能奏效。 您甚至不需要摆脱旧的“终端”窗格-只需将其隐藏即可(如现在),并可以用包含“终端”选项卡的普通“编辑器”窗格替换。

Cloud9中的Terminals的另一个好处是,它们连接到(IIRC)tmux实例,而不是直接终端。 这使得前端可以重新缩放(即关闭)而不会丢失终端进程,并且可以平滑地附加到新客户端(此功能对云VS Code用户非常有用),甚至可以与其他客户端共享实例(管理程序)级)用户。

有扩展做到这一点的内置VS码端,但如果你正在寻找一个终端的抽象,它会被冷却到捆绑dtachabduco

可以在UI中与编辑器选项卡互换的终端选项卡

这真是太好了。

我们可以摆脱底部的控制台,并将其所有窗格(“问题”,“输出”,“调试”控制台和所有终端)变成常规的编辑器选项卡,可以根据需要打开这些选项卡,每种窗格类型都有一个特定的图标。

作为参考,扩展信息页面,设置UI,键盘快捷键以及可能的其他内容已通过这种方式处理,作为带有自定义图标的常规编辑器选项卡。

这将使人们可以使用现有功能来拆分和排列终端,并使用现有功能来拆分和排列编辑器标签。

当然,即使关闭相应的编辑器选项卡,终端也应在后台继续运行,可以根据需要重新打开该选项卡。 使用tmuxdtach来保持终端会话在VSCode重新启动期间运行的其他建议也是一个好主意,但这属于另一个问题。

image

使用新的webview api,我们可能已经可以做到这一点。
但这意味着您需要自己编写所有launch.json处理,这并不理想。

但是,使它成为编辑器“选项卡”有一个好处,因为编辑器选项卡可以具有序列化/反序列化处理程序。
这样就有可能给予终端保存和恢复的行为。 (例如,保存tmux会话ID并在还原时重新附加)

POC: https

@ mmis1000,现在肯定可以使用webview API进行构建,但是它将缺少所有集成,命令,诸如链接处理,扩展api访问之类的功能,并且通常只充当单独的东西。

https://github.com/microsoft/vscode/issues/20013中跟踪了保存和还原功能

@Tyriar实际上,我实际上是生成了一个Terminal实例,并将其用作底层pty实例,因此至少像git Integration这样的东西可以正常工作(看起来它需要将一些env传递给终端)。

但是,事实证明暴露的api vscode太有限了。 它不仅没有公开底层的pty进程,也没有公开stdio和终端功能,例如pty resize。 使其完全不可能用作pty来源。 因此,我被迫自行产生pty。

POC: https

嘿, @ mmis1000 ,您可以添加一些安装说明吗,那太好了。 真的很想拥有这个。

@ mmis1000受到设计的限制,因为它应该是核心产品的一部分, window.onDidWriteTerminalData事件也存在性能问题,这就是为什么它被提议保留。 虽然这种扩展可以用作临时解决方案,但我担心一旦我们让终端在编辑器区域内工作,用户的潜在长尾巴。 您可能最终遇到的另一个问题是依赖于vscode附带的node-pty,这不是供消费的公共API,将来可能会破坏您的扩展。

@Tyriar作为cloud9用户(现在仍然是cloud9用户)。

仅将任何屏幕区域用作终端,并使用tmux支持持久会话,这很有帮助。

我主要只是将cloud9用作Web终端来控制VPS。 (这是我现在仍然使用它的唯一原因。因为vscode在终端上确实做得不好。每次意外重新打开终端,这是一个巨大的痛苦)。

在昨天关闭浏览器之前,Cloud9始终会显示与您看到的相同的窗口,相同的编辑器,相同的终端和相同的会话。 如果找不到会话(也许服务器已重新启动),它将至少为您重新打开一个具有相同环境的会话。

如果我打算使用另一种在线编辑器服务(我的意思是,在浏览器中打开),我有点希望它支持开箱即用(或至少可以通过扩展实现),因为您不太可能不关闭浏览器(完全是出于故意或偶然)。

(而且因为cloud9是在几年前完成的,所以我真的不觉得这是一个技术问题)

老实说,我提供的终端体验vscode并不是真正的最新产品。

@ mmis1000您能否添加一些安装说明?

https://github.com/mmis1000/Vscode-terminal-tab存储库具有自己的问题跟踪器。 任何需要询问该项目的人,请在那里询问。

ezgif-2-8012d10efb96

对于我希望在基于远程ide /基于浏览器的ide上看到的终端的演示。
我希望它在昨天关闭时仅恢复标签位置/终端会话。
代替It will kill the all the important tasks I am running instantly because I accidentally close the the browser / the browser crashed / the computer BSOD

@xgdgsc看起来可能,但不是。

我期望的是即使在本地vscode实例上,终端持久性也是普遍可用的。 (至少到iterm2为止)
为什么需要将这种有用的功能限制为远程连接?

而且我也没有持久的ssh连接,我只是连接了一些终端多路复用器并在那里运行。

再次在https://github.com/microsoft/vscode/issues/20013中进行跟踪的@ mmis1000 ,有关最新信息,请参见此处。 尝试关注主题,因为当您对此问题发表评论时,会有很多人收到通知。

在接下来的迭代中是否有机会拥有此功能?

将终端打开为普通的编辑器页面选项卡对我来说是一个好主意,我非常需要此功能。

此页面是否有帮助?
0 / 5 - 0 等级