Explore ways to not pollute editor groups with terminals with other editors

[Tyriar]

We're approaching adding terminal editors (tracked in #10546) but one problem we foresee coming is that users will want to lay out their terminals for example like this:

|------|------|
|      |      |
|      |------|
|      |      |
|------|------|

Where there are 1 or 2 fixed terminals on a side. For this I think it's not desirable that when you open a file while the terminal is active that it will add it to the terminal's group as it's essentially acting as a dedicated terminal group.

For terminals we could approach this by saying don't open text files in terminal-only editor groups, but I think it's worth considering generalizing the solution since same problem applies to regular text files too:

• I use split editors to show a reference on the right, I never want a second tab over there
• Markdown preview on the side has the same issue

How about having another state for editors groups similar to pinned for editors, where file don't open in them and instead go to the closest editor group to the right or something?

cc @meganrogge

[bpasero]

How about having another state for editors groups similar to pinned for editors, where file don't open in them and instead go to the closest editor group to the right or something?

Without thinking about the UX impact, but conceptually: a property on editor groups that makes sure non-editable editors go into a separate group? Or a property to put all the editors of one type into that one group? How would such a group flow when editor layouts change, i.e. would it be enforced that the group is always to the right hand side of the other groups?

I wonder if it wouldn't be easier to add another editor part to the right hand side of the editor part that houses terminals?

[Tyriar]

We had a call about this and came up with the idea for "locked editor groups", basically a little lock icon woulds appear to the left of the tabs for the editor group and files opened via explorer/quick pick would not open in that group if it has focus.

There is also the much simpler idea of inverting the concept and supporting a "main editor group" where all files get opened instead, I kind of prefer this approach as it should be very simple with just a setting like "workbench.editor.mainEditorGroup": "1" and maybe a new API to get the preferred/main editor group if needed.

cc @misolori

[bpasero]

I personally feel that locked editor groups are nicer to work with because I see use cases beyond the scope of terminals. E.g. if a user wants to always keep 3 editors in one group (model, view, controller, etc - maybe even pinned?) and have all other editors open around that in separate groups, I feel that could be a use case for locked editor groups too.

The one-off setting to make an editor group a main or "default" editor group feels a bit unnatural to me, esp. not sure how the UI could indicate this behaviour visually.

Anyhow, if we could have some designs to talk through for both ideas, that would be helpful.

[rebornix]

I would prefer to have a locked editor group, in which a user can have some files open/pined always. For example, I can have inbox, my-work and my-endgame notebooks open in a locked group for the whole endgame week, and they will not override by files opened through quick open.

With that being said, I wonder if this would add complexity to API or even internals (open editor input in a specific group).

[miguelsolorio]

Here's a first draft at using this secondary editor group, using the terminal as an example. A couple of things that are happening here:

• Dragging a terminal into a new group will cause it to go into a "locked" group (you can also do this on any editor group via the right-click context menu)
• Once a locked group has been created, you can only drag files into this area or split from one of the locked files
• Opening files will cause them to be opened outside of the locked group
• Once you close all the files in the locked group, the group goes away
• For the terminal, if you drag the terminal tab into an existing (non-locked group) then it will inherit whatever type the group has (and vice versa)
• For the terminal, once all terminal editors have been closed, the default terminal tab will be reset in the panel

CleanShot.2021-06-15.at.22.35.07.mp4

[bpasero]

Yeah this is nice and goes into the direction of what I had in my mind too. Some discussion items:

• how does this look like when tabs are disabled
• should the gear icon be clickable to toggle between lock and unlock? and if so, what would happen once you unlock, does the icon stay?

And some feedback:

Once you close all the files in the locked group, the group goes away

I think this depends on the user setting to close empty groups or not. This brings up an interesting question how to show this in an empty group where we have no tabs. We do not really have a title area then either.

Opening files will cause them to be opened outside of the locked group

We have to decide which one to pick e.g. if there is a group to the left and to the right of the locked one...

Once a locked group has been created, you can only drag files into this area or split from one of the locked files

To expand on this: we have API in the workbench to explicitly pass in a group or pass in wildcards such as "active group" or "side group". I would argue that any command that passes in an explicit group will work even in a locked group (e.g. the drag and drop scenario) and all the others will pick a different group if the group is locked. I bring this up because there are more commands that will target a group specifically, e.g. "Move active editor into next group" where we should maybe allow this even for locked groups.