Tabs that group editor grid layouts (Vim-style tabs)

[thefakeplace]

I'm breaking this out into a separate issue from #36700.

The discussion in #36700 got a little confusing because of users being sent there from any Vim-style tabs FR #41486, #104483, VSCodeVim/2989, even though the FR in #36700 is quite different.

---

Currently, VSCode supports tabs inside of editor groups, where each tab has a one-to-one relationship with a file-- so, effectively, a tab can't really group anything in VSCode.

In Vim and some other editors, a tab groups a set of splits. For example (from my own VSCode fork):

The key thing to notice here is the higher-order tab bar on the top.

This lets me group multiple editor groups inside one tab.

When I want to think about my parser, I can open the implementation, AST node definitions, and tests with one click/hotkey (for me, cmd + 1-9) or fuzzy search of the tab titles.

Same thing for my lexer-- impl, grammar, and tests.

For webdev, similarly-- component impl, template, and tests.

Some way to save/reload editor grid layouts (without this exact tab bar UX) would serve the same purpose.

---

It would be cool if I could distribute what I have now as an extension, but the extension API's don't currently provide all of the functionality required (not just the extra workbench part for the tab bar, just reloading a layout in general is flaky without source access, see #15178).

This extension already exists too, which is also pretty close, but suffers from the same issues I ran into when trying to convert my fork into an extension.

Ideally this would just be supported as a first-class use case from VSCode. There's a lot of UX ambiguity that comes up when you hack in this feature via extension, and I think the only way to get an experience that makes sense is to have VSCode implement it.

[anthony-whale]

@thefakeplace can you publish the modifications you made as a github repo? I wouldn't mind running your fork of VSCode to get this functionality.

[thefakeplace]

I'd love to but my implementation sucks-- it serializes/deserializes the entire higher-order tab so the only thing that really works well is editors (terminals and other things lose state, for example).

And in general, it's quite laggy on lower-end machines when you swap tabs.

I might try to improve the implementation in the future, and then I would be happy to share, but for now this works for me and I don't have much time or energy to work on it..

[ldelossa]

This is the one feature stopping me from using VSCode on the daily.

There is no way to segment a group of tabs.

This is useful when you are working with a repository that vendors in its dependencies. You may want to jump into a vendored repository but you want to explore that sub directory in its own fresh "workspace".

Right now I think most would open another vscode editor, but then you are now running two language servers which uses twice the memory as necessary.

[distek]

I've done a terrible thing but I'm working around it with this right now: https://github.com/distek/tabgroup-sync

Please for the love of all that is good in the world fork/rewrite it and make it not terrible.

[aguynamedben]

Before implementing this please study the history and functionality of Emacs "buffers" and "windows".

• Frame - The main window of Emacs
• Window - A visual section of the Frame. There can be one Window, but you can also split a Frame vertically or horizontally into many Windows
• Buffer - An open file in memory, has nothing to do with the UI

The user can view any buffer in any window without re-opening the file. To me, VS Code's main UI problem is they too closely tied the idea of splitting the UI to the idea of tabs and tab groups, and now there's baggage.

In Emacs, a user wanting a three-wide user interface can do:

• A single frame, maximized (i.e. "window" in VS Code)
• Split the frame into three "windows" (i.e. "visual split" in VS Code)
• 50 open buffers, i.e. these are just open files in memory

The user can move between the three windows, and from any window they can recall any buffer (open file). This is a very flexible system that doesn't lead to never-ending feature requests or tweaks to how tabs work.

In VS Code the idea of "open file" needs to be unbound "tab", "tab groups", and splitting. Maybe VS Code should just call a file open in memory an "editor" and rework the UI so that tabs, tab groups, and splits can display any "editor" (open file, "buffer in Emacs). The default can still be "when a file is opened, we create a new editor, and in turn that creates a new tab" but sorting out the Information Architecture so that splitting, tabs, tab groups, and open files are all a bit more independent seems like it'd be a huge win for how the VS Code UI works.

[darianmorat]

If you wanna imitate the behavior of group tabs that is used in VIM you can do this:

keybindings.json:

 {
      "command": "runCommands",
      "key": "ctrl+1", // whatever keybinding
      "args": {
         "commands": [
            // commands to run in sequence
            "workbench.action.focusFirstEditorGroup",
            "workbench.action.toggleMaximizeEditorGroup"
         ]
      }
   },
   {
      "command": "runCommands",
      "key": "ctrl+2", // whatever keybinding
      "args": {
         "commands": [
            // commands to run in sequence
            "workbench.action.focusSecondEditorGroup",
            "workbench.action.toggleMaximizeEditorGroup"
         ]
      }
   }

If u press just 1 time ctrl+1 is going to send just that group of tabs, same with ctrl+2. And if you want to see again the groups, you can just press 2 times ctrl+1 or ctrl+2 and again same if you press it 1 time.

[bew]

@darianmorat I think you misunderstood the goal of this issue. We don't want groups of tabs, but groups of editor groups (which are groups of tabs, all organized in a specific layout)

[darianmorat]

@darianmorat I think you misunderstood the goal of this issue. We don't want groups of tabs, but groups of editor groups (which are groups of tabs, all organized in a specific layout)

Ohh got it, yeah is quite complicated, I think the only thing close to that would be adding the workbench.action.splitEditorInGroup and you'd have splits on different groups. But I think the limitation is just for 1 tab in the same file and not having two different files in different groups split at the same time

[thefakeplace]

yeah i agree, the limitations are kind of weird-- i think emacs and vim really nailed the model, and vscode has grown to be pretty awesome but the model for splits/buffers is just downright weird imo

[pzuraq]

Just want to chime in here as well, as a user with many, many open tabs frequently, I've started working on an extension for better tab management (basically an alternative to the default tab bar/open editors view). Part of my goal is to have more automatic arranging and visual grouping of tabs in the tab bar, but ideally it would also be possible to organize splits in the tab bar for related files.

In the meantime I'm going to come up with something in between, but would love to see this functionality (also, I can take a stab at making a PR too if there would be support to merge it)