Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Tabs for integrated terminal #10546

Open
Perkovec opened this issue Aug 15, 2016 · 305 comments
Open

Tabs for integrated terminal #10546

Perkovec opened this issue Aug 15, 2016 · 305 comments

Comments

@Perkovec
Copy link

@Perkovec Perkovec commented Aug 15, 2016

Status update from @Tyriar:


Feature request.

Default terminal

image

But could be more usable...

terminals2
terminals1

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Aug 15, 2016

The tabs were originally considered but widely panned by the team as it could cause confusion having tabs at the bottom and make vscode feel less "light-weight". If I didn't have keybindings for focusNext and focusPrevious terminals I would get very frustrated by the lack of tabs since dropdowns are a pain to use.

Also split view was considered and then deprioritized as applications like tmux can run in the integrated terminal to achieve a similar result, I've since pivoted from this and really want to be able to split the terminal. I don't particularly want to learn tmux's keybindings and part of my workflow is to have multiple terminals displaying at once; typically a watch command that I monitor for errors and a manual build or launch command. Let's track splitting the terminal in #7504

@stevencl @bgashler1 please weigh in on tabs again keeping in mind that I could not find reasonable default keybindings for the terminal's focusNext and focusPrevious actions (I bind ctrl+shift+j/k).

@Tyriar Tyriar changed the title Tabs and split view for integrated terminal Tabs for integrated terminal Aug 15, 2016
@Tyriar Tyriar added this to the Backlog milestone Aug 15, 2016
@stevencl
Copy link
Member

@stevencl stevencl commented Aug 16, 2016

We need to consider this in the context of this issue though: #9659

I'm really wary of a tabs within tabs design. We'll end up just using all the available space to show tabs :-)

Just thinking out loud here, do we really need to show tabs if we allowed splitting the terminal? Would it be enough if we just exposed actions to split and collapse the terminal but didn't have to show the actual tab?

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Aug 16, 2016

Maybe, I can see myself using 2-3 split terminals over tabs/multiple terminals. Managing split terminals and tabs terminals would get very confusing and probably barely get any use due to lack of keybindings.

@bpasero
Copy link
Member

@bpasero bpasero commented Aug 16, 2016

If we open the door to splitting terminals, what would it mean for splitting e.g. one terminal and one debug repl? is it the same UX interaction?

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Aug 16, 2016

@bpasero by splitting I mean create a new terminal to the side, so yes it would be the same.

To simplify the interaction there could be a setting to always use either the dropdown or split the terminals. That way all the existing commands would still work fine, you just choose to show 1 or all terminals at any time.

@bgashler1
Copy link
Contributor

@bgashler1 bgashler1 commented Aug 16, 2016

The fear I have with introducing tabs and splitting to the terminal is that it may look like an editor group. I don't want users to be disappointed that they can't drag editors into the terminal or terminals into the editor groups.* Also, introducing this may be a slippery slope in window management, such as why do we even have a special horizontal panel for things like this in the first place. Why not just let a terminal live wherever it wants, instead of replicating so much functionality in custom UI.

*possibly we could inform them of the limitation by locking dragging on the x-axis and/or having a disabled-cursor when trying to drag outside an area, but it's difficult to avoid people expecting this to work.

When we introduce horizontal splitting of editor groups, one of the constraints we're imposing is that editor groups can only be horizontally split or vertically split. So it may be uncanny for users to have a panel that looks strikingly similar to a horizontal editor group (but it doesn't behave exactly the same way) sitting below vertical editor groups.

We should talk more about this during UX sync on Wednesday. There are some designs I didn't show last time related to horizontal layouts that are relevant to this

@nick-walt
Copy link

@nick-walt nick-walt commented Aug 17, 2016

What about the option of aligning the terminal with the editor tab, so that the terminal automatically reflects the language of the editor file?

Opening a terminal would automatically load a preconfigured shell for the active (currently selected) editor's language. Multiple terminal shells must be supported in the settings.json file.

It doesn't matter how the editors are split - the terminal always shows the shell for the selected (active) editor. This is simple and straightforward. With this method there is no need to split the terminal, no need for tabbed terminals. The terminal would continue to appear as it does now.

If there are multiple shells available for the language, or you want to run a configuration like node shell and a git shell for the one editor tab, then perhaps the shells can be selectable within the one pane. This is a bit like tabbed terminals, except they are not presented as hard tabs, which implies a sub-context. This doesn't 'feel' substantial like a tab. Their context is within the terminal pane for currently selected editor.

A simple hypertext string (one for each shell) located in the top right of the terminal will show the shells open (instantiated) for the currently selected editor. A user can either just click on a hypertext string, which might say node, to select it, or use a key binding to cycle through. These will replace the existing drop-down menu, the +, and the trash can. The shells could possibly be presented in lowercase.

Either a simple hypertext string could be shown or just an icon - although, a string might be better. This would replace the cumbersome drop-down list currently used in VSCode and show the shells at a glance.

When you switch focus from the current editor, to an editor with another language (say, Ruby), the terminal will present the IRB instance in the terminal. If the user wants to open another instance of the current shell they might only have to hover over the hypertext for that shell and click the + that will appear. If the hypertext strings are short - like node, irb, cmd, ps - another string can be created next to the string used to create the new instance. The strings would move apart to make room but wouldn't become cluttered because a limit could be set (who is going to open more than three shells against an editor?).

Hovering over a shell might also be able to present a peak, that shows the shell content for that string. Though, if users are using key bindings to switch/cycle it might just be easier to check with that.

If you wanted to give the user the option to add a shell not associated with the editor, like a git shell, clicking the + could present a menu of shells registered in the settings.json file. The - that would appear on hover next to each hypertext string would, of course, not show any options. It would close the current shell instance.

If a user wanted to change the shell type, they could exit from the shell (to fall back to the default) and then launch a new shell by typing the shell name. The hypertext string representing the shell would change to reflect the new shell.

In the case of a git shell, it might be logical to offer the option for the user to specify that a git shell will always be opened with the editor's language shell, so that git is in context to that file location. If multiple files are open from the same git location, all git shell instances across all editors will reflect the latest update or command.

The settings.json file will likely require the user to enter the specific language extension (.js, .cs, .rb) against each terminal.internal.shell. entry so that there is a logical match up to a file. A default shell can be configured for any file type not specified in settings.json.

The shell instance loaded for each editor lasts as long as that editor is open. As soon as an editor (a file) is closed, the associated terminal shell(s) are also closed.

I believe that this is a simple implementation that will also make VSCode more powerful than it currently is, while being very intuitive. When the user switches contexts across language editors they don't have to think about the terminal. The terminal will always present the shell and the code last run, including the associated history, etc, that was last used for the selected editor.

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Aug 17, 2016

@nick-walt while it may be more intuitive to some, it's not at all intuitive to others. It would likely cause people to get somewhat disoriented and wonder where their shell went. Also my requirements are to have 2 shells displaying at once; one for a watch task that I'm tracking errors in and one for a launch task, git, build, etc.

Multiple terminal configurations has come up before, I'm not so sure it's worth the additional complexity though when most of the time you can just run the shell in your other shell (opens powershell, ruby, node, etc. within cmd).

@nick-walt
Copy link

@nick-walt nick-walt commented Aug 18, 2016

@Tyriar
Those are good concerns, but I think that they can be solved fairly easily when taken on as considerations.

Avoid disorientation
In its default state, in an unconfigured new installation, the terminal can behave in a familiar way. This avoids disorientation from an unexpected behavior.

Splitting the terminal
Splitting the terminal pane doesn't change the model. It's just a way to view more than one shell in the terminal pane at a time. It could be possible to drag the pane out of the main window and go full-screen on another monitor. Then the user can tell the terminal to split automatically and evenly between the open shells, vertically or horizontally. One terminal, multiple shells - all in context with the currently selected editor.

Watching
If we don't want to lose sight of a shell instance that we're watching, while you switch to another editor, then perhaps a watch feature that shows a configurable number of lines could solve this problem. If an error occurs this can also be shown as an icon in case the user missed it due to fast scrolling. This is already done in VSCode's Error pane. A watcher panel could be display only and hovering over it could show a bigger sample.

Sophistication without the burden of complexity
With a contextual terminal the ability to have many shells across all of your editors won't feel overwhelming or taxing. Given the right model the UI/UX guys can make it work elegantly.

I think your concerns could be fully addressed.

@wclr
Copy link

@wclr wclr commented Aug 19, 2016

It depends for what terminal is going (supposed) to be used. If it is going to be used to run some one time command then multiple terminals are hardly needed in any manner.

Multiple terminals are needed if they are going to be used to run concurrently multiple background tasks, such as serving, building, watching, tests etc.

So in this case it is viable to have quick overview what terminals are opened and what they are running (with presumably the state of the run). I'm not sure how it can be done without named/maked tabs.

Split view is also needed because on wide screen there is available place at least for more then one terminal.

One more question is cooperative use with task runner. Which is currently used to run only one task at a time. But this #981 assumes that it is going to support multiple background tasks - so it is a like (I wouldn't say conflicting) purpose as for multiple terminals.

Jetbrains Webstorm currenlty has such capabilities - it can run multiple tasks (defined via grunt/gulp/npm) and multiple terminals (with named tabs). And you also may use there a split view where one one side you see running tasks, and on the other - terminal. (attaching the screen)

image

@nick-walt
Copy link

@nick-walt nick-walt commented Aug 20, 2016

@whitecolor

Okay, so if we list all of the scenarios and their commonalities it should be possible to distill the required functionality to elegance that can address diverse usage - without VSCode becoming too heavy.

Much'o tabs without fatigue
With a terminal bound to the context of an editor the issue of a usability disconnect (such as which tabs associate to which editor) the use of 'soft tabs', aka a hypertext string naming the shell within the terminal/editor context, will allow many more tabs without causing the user to go tab hunting and avoid context/association fatigue from keeping track in their head.

Named shells
With the idea of a simple hypertext string showing the name of a shell instance within a terminal pane comes the possibility of an alternative creation and naming. So, a user has a single shell configured in settings.json, which might be 'cmd'.

Once they are in a shell they can either jump into another shell, like 'powershell' or 'bash', and the hypertext string named 'cmd' in the terminal header can change to reflect the shell in which the user jumped to.

Or, the user can create an additional shell instance from the starter 'cmd' shell maybe by using a command the terminal pane understands as creating a "new ".

The idea is to imply in the UI the fact that the named shells are not dis-associated tabs but shells within the parent editor. I'm using the term 'tabs' to denote a dis-associated and self-contained shell that is separate to anything else. This could be a mode, where hard-tabs are global, and soft-tabs are within an editor context.

If a hard-tab/soft-tab mode was included then perhaps the hard tabs could have hard boarders, much like tabs showing editors. The behaviour of the names would be identical to soft-tabs.

The critical thing is to maintain the established UI/UX model. We've all seen plenty of instances where models are broken across different UI implementations within a single app. Actually, Microsoft is good at this (and more of late, Apple). It's a classic case of 'design by committee'.
established

Simple, single shell user
However, if a user wants to run simplified and a single terminal/shell then there is nothing in the way of achieving that, and importantly, the configuration is simple. It's just another usage scenario in the consideration matrix.

@W4RH4WK
Copy link
Contributor

@W4RH4WK W4RH4WK commented Aug 27, 2016

If tabs are going to be added, I'd like to have a config option to disable them / force a single instance of the integrated terminal. If I require such advanced features, I typically resort to using the (external) terminal of my choice.

@wclr
Copy link

@wclr wclr commented Aug 27, 2016

I would aslo consider such thing as terminal split (more advanced split) so all the running (maybe more then two) important terminals outputs where before the eyes even partly.

@cescoferraro
Copy link

@cescoferraro cescoferraro commented Aug 31, 2016

How about showing the terminal tabs at the same place as file tabs?
It would not polute the UI and no functionally would be lost.

@christianmalek
Copy link

@christianmalek christianmalek commented Sep 1, 2016

@cescoferraro I like this idea. But then VS Code should also support vertical splitted tab views and not only horizontally. Otherwise it wouldn't really meet the condition to see multiple terminals without wasting space.

@cescoferraro
Copy link

@cescoferraro cescoferraro commented Sep 1, 2016

@Phisherman Do not get me wrong, I like the split terminal.
I use it a lot on Intellij with a big screen and lots of memory setup.
Whatever the decision is, it should be pluggable if hogs to much memory to keep VSCode as fast as possible.

@wclr
Copy link

@wclr wclr commented Sep 1, 2016

I've wrote an extension with that you can select npm/gulp task, it will launch the terminal (with task name) and run it there, also will place an item on the status bar which you can click any time, as well it does basic tracking of the running process state.
image

Just to show possible "tabs" location, they could be at the bottom of the teminal.

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Sep 1, 2016

@whitecolor 😮 this is using the new terminal API? That's awesome!

@wclr
Copy link

@wclr wclr commented Sep 1, 2016

@Tyriar Yeah, that one you are working on 😉

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 2, 2021

Tabs are about to be enabled by default (v1.57) after many improvements and fixes done in the last month 🎉

Screen Shot 2021-06-02 at 5 05 00 AM

Screen Shot 2021-06-02 at 5 05 37 AM

The plan is to work on "editor terminals" in June (v1.58) which will enable dragging and dropping terminals into the editor area. This will also let us finally close this issue off.

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 14, 2021

I've filled in an issue for the plan at #125514, we're going to start work on the "terminal editors" feature today. Feedback is very welcome 🙂

@Igorgro
Copy link

@Igorgro Igorgro commented Jun 15, 2021

I don't know is it a bug or not, but sometimes bash terminal use 'console' icon instead of expected 'bash' icon.
изображение

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 15, 2021

@Igorgro we can look into it in another issue if you want

@cgarrovillo
Copy link

@cgarrovillo cgarrovillo commented Jun 15, 2021

Is there a way to keep the tabs panel always open, even if there is only a single terminal?

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 15, 2021

@cgarrovillo

"terminal.integrated.tabs.hideCondition": "never"

You might also want to use:

"terminal.integrated.tabs.showActiveTerminal": "never"
@jasonwilliams
Copy link
Contributor

@jasonwilliams jasonwilliams commented Jun 16, 2021

@Tyriar slightly offtopic, what keybinding do you use to focus back up to the editor whilst keeping the terminal open? (and vice-versa from the editor)

@yume-chan
Copy link
Contributor

@yume-chan yume-chan commented Jun 16, 2021

@jasonwilliams I think you can use the workbench.action.focusActiveEditorGroup command. It doesn't have a default keybinding but you can assign to whatever key you want. For example:

  {
    "key": "ctrl+shift+j",
    "command": "workbench.action.focusActiveEditorGroup",
    "when": "terminalFocus"
  }

For focusing back to terminal, workbench.action.terminal.toggleTerminal (Ctrl + ~) command will work

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 16, 2021

@jasonwilliams I use ctrl+1/cmd+1 if I want to do that.

@wenfangdu
Copy link

@wenfangdu wenfangdu commented Jun 19, 2021

@Tyriar @yume-chan

How to construct the When condition for joining terminals (workbench.action.terminal.joinInstance)?

Necessary conditions I can think of:

  1. Terminal tabs are focused.
  2. Two or more terminals are selected in the terminal tabs.

The best I came up with is:

terminalProcessSupported && terminalTabsFocus && !terminalTabsSingularSelection

But the above is not the same as terminalTabsMultipleSelections (which doesn't exist).

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 19, 2021

@wenfangdu we use internally to make it work in the context menu terminalProcessSupported && !terminalTabsSingularSelection

@wenfangdu
Copy link

@wenfangdu wenfangdu commented Jun 20, 2021

@Tyriar I think terminalProcessSupported && !terminalTabsSingularSelection is not the same as terminalTabsMultipleSelections (which doesn't exist yet).

terminalProcessSupported && terminalTabsHaveSelections && !terminalTabsSingularSelection is more accurate, but terminalTabsHaveSelections doesn't exist too.

Can you consider adding these conditions if they are necessary?

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 20, 2021

@wenfangdu what's your use case exactly and why doesn't the singular one work? Note that these are "internal" context keys that we haven't documented and discourage their use as they could change at any time https://code.visualstudio.com/api/references/when-clause-contexts

@nk-dm
Copy link

@nk-dm nk-dm commented Jun 20, 2021

I think a "kill all" button(e.g. a trash-can on the top bar -- next to the hide cross) would be useful. For instance, I often have lldb open in one tab and vim(use it since one of the languages I use only has a syntax highlighter for vim) -- searching for bugs(that language also doesn't have a debugger, so I have to bodge it like this). But once I'm done I would like to kill all these windows at once.

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 20, 2021

@nk-dm you have a few options which makes killing all fairly easy:

  • Add a keybinding to kill and hit that n times
  • Click the bin icon n times, we keep the tabs open now even when there is a single tab to make this easier
  • We're bringing back the panel bin icon so hit that n times.

If you're really keen on a kill all command it should be very easy to make an extension for that and hook it up to a keybinding.

@wenfangdu
Copy link

@wenfangdu wenfangdu commented Jun 20, 2021

@wenfangdu what's your use case exactly and why doesn't the singular one work? Note that these are "internal" context keys that we haven't documented and discourage their use as they could change at any time https://code.visualstudio.com/api/references/when-clause-contexts

@Tyriar Sorry for not explaining clearly, my point is !terminalTabsSingularSelection is a superset of terminalTabsMultipleSelections, if the terminal tabs have no selection, judging by the name, !terminalTabsSingularSelection is still true, but terminalTabsMultipleSelections will be false, unless the actual implementation of terminalTabsSingularSelection contains no selection case (does it?).

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 21, 2021

@wenfangdu but what you you trying to accomplish and what's the problem you're seeing?

@wenfangdu
Copy link

@wenfangdu wenfangdu commented Jun 21, 2021

@Tyriar My current When condition for workbench.action.terminal.joinInstance is terminalProcessSupported && terminalTabsFocus && !terminalTabsSingularSelection, and when focusing the terminal tabs area without selecting any tabs, using this command will throw Cannot read property 'shellLaunchConfig' of undefined.

VSCode: v1.57.1
OS: Windows 10

Tyriar added a commit that referenced this issue Jun 21, 2021
@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 21, 2021

@wenfangdu thanks, fixed the exception getting thrown so it's just a no-op when you run with <= 1 instance selected in 64ff30c

@nk-dm
Copy link

@nk-dm nk-dm commented Jun 24, 2021

@Tyriar

  • Click the bin icon n times, we keep the tabs open now even when there is a single tab to make this easier

This would be easier if ongoing processes weren't marked with a moving circle thingy that pushes the bin icon to the left(making the not aligned).

  • We're bringing back the panel bin icon so hit that n times.

Good idea, looking forward to that.

@sagebind
Copy link

@sagebind sagebind commented Jun 24, 2021

I know its been a long time to get here, and I know this is still in development, but after playing around with the latest Insiders I feel the need to give some early credit to where its due: It's so beautiful!

Screen Shot 2021-06-24 at 1 50 27 PM

This is basically exactly what I've always wanted, glad to see its coming along nicely! 👍 I look forward to a noticeable improvement to my workflow once released. In Insiders there's a few things not implemented yet and there's a bug or two, but overall its already quite useable.

The bug I ran into was this: I was creating, rearranging, and destroying a bunch of terminals (as you do) and at one point when I tried to close a terminal editor I got an error instead (from the console) and the tab went blank:

[2021-06-24 13:40:45.631] [renderer1] [error] Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.: Error: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.
Stack trace
  at e.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm-addon-webgl/lib/xterm-addon-webgl.js:1:18970)
  at Object.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:143534)
  at t.e.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:219708)
  at t.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:146376)
  at t.e.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:219708)
  at t.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:173034)
  at t.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:43060)
  at e.dispose (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js:1:307866)
  at fi.dispose (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2718:85163)
  at vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:1521:38328
  at Object.dispose (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17:12535)
  at C (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17:12257)
  at h.clear (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17:12717)
  at h.dispose (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17:12696)
  at k.dispose (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:17:13231)
  at k.dispose (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:1503:57284)
  at Ii.handleOnDidCloseEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:10701)
  at vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:9622
  at r.fire (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:60:1835)
  at ki.closeEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:1503:86730)
  at Ii.doCloseActiveEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:19701)
  at Ii.doCloseEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:19289)
  at Ii.doCloseEditorWithDirtyHandling (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:19140)
  at async Ii.closeEditor (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:2543:18969)
  at async O.runAction (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:171:30929)
  at async O.run (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-%20Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:171:30829)

I haven't been able to reproduce it though.

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 24, 2021

This would be easier if ongoing processes weren't marked with a moving circle thingy that pushes the bin icon to the left(making the not aligned).

@nk-dm this is how we render decorations everywhere so I don't think we would be able to change that behavior. An alternative is to use delete while in the tree.


@sagebind awesome! We keep a very up to date list of bugs and remaining work in this query, some fixes will be in main but not released for a day though (or more over weekend). There are still some annoying ones we're tracking down related to the panel showing when no terminals are there and reconnecting not working consistently.

@ardunster
Copy link

@ardunster ardunster commented Jun 24, 2021

I'm looking forward to this as I recently ended up with a workflow where I need three different terminal tabs (and I keep them open/split) and having them a) repopulate in a random order when I reload the window and b) not be able to drag and drop them to rearrange them is driving me nuts.

@Tyriar
Copy link
Member

@Tyriar Tyriar commented Jun 24, 2021

@ardunster the random order one is tracked in #127090, drag and drop will be fixed in tomorrow's build

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet