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.

[hediet]

should the gear icon be clickable to toggle between lock and unlock?

I think it would be nice if users can lock arbitrary editor groups, maybe by using some context menu?
I think this feature might be useful for all webviews that provide some navigation features (e.g. like this extension).

Also, sometimes, I want to have an editor group that I fully control and that is not "spammed" with editors that I open later.

[bpasero]

From our last UX call where @kieferrm was also there to speak we would like to explore 2 variants behind experimental settings:

• locked editor group [1]
• default editor group [2]

Locked Groups
A locked group refuses to open anymore editors unless explicitly specified by the user or API (e.g. via drag and drop). Instead, the next neighbouring group that is closest to the locked group will be picked unless that group is locked too. To make this work we probably need some API for terminals to indicate that the group they open in gets locked automatically if no other editor is present in that group. If we go down with this approach we probably want some indication for locked groups and maybe a UI gesture to mark a group as locked or unlocked.

Default Groups
A default group is the target for every editor that opens unless otherwise explicitly specified by the user or API (e.g. via drag and drop). By default the first editor group would be the default group, but it is possible that another editor group becomes the default group if the default group is closed. If we go down with this approach we probably want some indication for the default group and maybe a UI gesture to mark a group as default or not.

[bpasero]

I have explored the one variant: to be able to lock editor groups:

Current behaviour:

• this can be enabled/disabled per each group via "..." or commands
• terminals are configured to lock a new group automatically when opening (behind a setting)
• locked editor groups refuse to open editors unless explicitly chosen by the user (e.g. via DND)
• locked state is preserved across reloads and even for empty groups (provided the user has configured to not close empty groups)

There is no real visual indicator (yet) to reflect a group is locked other than a toggle in the "..." menu when you open it. I have explored 2 variants:

Lock icon in a left aligned toolbar

Lock icon in the editor group toolbar

The changes are in https://github.com/microsoft/vscode/tree/ben/locked-groups to play with and can present this in the UX call on Wednesday.

//cc @meganrogge @Tyriar @stevencl @misolori @kieferrm

[hediet]

It would be nice if extensions can spawn a new webview in a new locked editor group.