Panes within tabs?

[bhuga]

I have a Vim workflow that I am having trouble recreating in Atom. Most of my tabs consist of a split, for a file and its tests:

Thus I can { and } my way through tabs and [ and ] my way through splits within them, and all was right with the world. My splits are about keeping related files together, not separate panes or editors.

The modeling of Pane and EditSession doesn't really allow this right now. It's fairly easy to see a number of ways to do it, but I was stymied when I started to edit core stuff by things marked as internal. @kevinsawicki said to ignore that, so I'm going to slowly work on something that works for me. But he also said to make an issue, so here it is. I'm hoping that one of you core guys sees a super easy way to do it :)

[nathansobo]

We should be able to have different PaneContainers as pane items, but I'm not sure it would work perfectly to just do that right now. I have some serious reworking of the pane system in mind after the current collaboration branch is merged. I suggest we give it another look when that is stable. This kind of thing should be attainable. If it isn't we should fix whatever stands in the way because many people prefer this workflow.

[lukemurray]

Any updates on this piece? I'm looking for the same functionality as I'm currently manually manipulating the DOM.

Is there a branch or some work being done that I could help with?

[nathansobo]

We don't currently have any work in progress on this.

[joaoafrmartins]

i am having some trouble implementing this functionality also...
there is a package making overrides of tab-views #2205 wich are currently not being exposed on worspace api... creating a new pane with a tab view is fairly straight forward by extending a view and registering an opener and calling open with split as an option... but when there are multiple tabs in a pane the pane created by the open call becomes blank.. and although the view still exists i am not managing to append it to the right tab... maybe i am doing something wrong... but some exposed funcionality on tab views would certainly help.. +1 on this...

i case you are wondering how to create a new tab inside a new pane

options =

      title: title

      split: split  #"right" or "left"

      searchAllPanes: true

      changeFocus: true

atom.workspace.open(uri, options).done (p) =>

    p.append @

this works but not really...

[nathansobo]

This is something we can address once our view system stabilizes in core. For now everything is so in flux that we're not really ready to focus on this in core.

[aggrhm]

+1 coming from Vim this is my biggest drawback right now. I use my tabs as different workspaces (like tmux also).

[bendavis78]

I could really use this as well. In my "pre-atom" workflow I used tmux and vim. It would be great to fire up one tab with 2-panes for my dev server and a commandline, and then subsequent tabs with various split panes depending on what code I'm working on. Basically I want my tabs to be workflow-centric, not file-centric.

[c10b10]

Moving my comment from #11349 here:

When I code, I conceptually split work into logically separate sections of the project, each of which involves working with multiple files at once: Data flow, Styling, UI components, etc. Surely I'm not alone.

Atom's current tab model sadly makes it difficult to map this way of working to the current workspace. I think we would all benefit immensely from changing it to Vim's model.

[trusktr]

I would love in-tab splits. Maybe we can keep Atom's current functionality and just add onto it. The current commands for splitting panes can remain the same, and new commands can be added that can make split windows (perhaps call these ones windows instead of panes, in order to differentiate?) inside of a tab. The end result would be that panes contain tabs, and tabs contain windows (named similarly to vim's windows).

[trusktr]

In NeoVim I like having files for a single component inside a tab. For example, a js file, html file, and css file, all split within a single tab. The workflow in Atom is quite different: it encourages bunching of similar files (for example, all CSS files in one pane, all HTML files in another pane, and all JS files in a third), so that the files for a single component can be visible all at once by selecting the appropriate tabs in each pane, but this will get in the way when trying to view other files that don't fit into the same component pattern. The splits-inside-tabs functionality would make it easier to group things (co-locate things) component-wise.

[trusktr]

Another idea could be to introduce an ability to switch Workspaces easily within a window, along with an extra UI around that feature to make it easy. Since Atom already has tabs on a per-pane basis, then maybe "workspaces" could be used to group panes together. After thinking for a little while, I like this idea better, and think that it would be better than NeoVim's.

But, since thetab UX feature is already used on panes, how would the workspace switching look like? Would it be similar to OS X's Expose (Mission Control)? Or perhaps more like Gnome 3's vertical workspaces?

On a side note, I'm making a 3D library at http://infamous.io (demos and docs coming soon), and I might like to implement something useful with it (for example, workspace switching).

Does anyone reading this know if it's possible to have multiple Workspace instances in a single window currently?

[trusktr]

Hmmmm, after researching the API for a little while, it seems that Workspaces have some functionality that we may not want to duplicate across some form of end-user "workspaces".

Maybe we can instead call this new feature PaneGroups, an have it strictly contain panes, so that the window's overall Workspace can still have things like top panels, etc, stuff that we wouldn't necessarily want to modify on a per-panegroup basis.

Question to anyone reading: would you like file tree instances on a per-panegroup basis? Or just one file-tree in the workspace, with pane groups containing literally nothing but panes (along with some way of navigating the pane groups)?

[trusktr]

Alright, so after taking a look at the Workspace class, it appears that Workspace is a proxy over PaneContainer (Workspace contains a single PaneContainer and some WorkSpace methods proxy directly to the PaneContainer methods).

It seems that in order to make this change I would have to modify (or extend) Workspace to make it possible for Workspace to contain multiple PaneContainers. But, the current WorkSpace design is implemented around the idea that a WorkSpace proxies to a single PaneContainer (essentially, WorkSpace is a souped-up PaneContainer). Because of this, it might possibly be easier to just have multiple WorkSpaces. Will have to think about this...

I'm completely new to Atom, so I'm not sure yet if it's possible to extend Workspace (and replace the class with the extended version) before it gets instantiated. If not, then it might not be possible to do this as an Atom package, and would need some modifications to Atom's Workspace class.

PaneContainer already is the pane-containing thing we'd want to take advantage of (rather than PaneGroup I suggested above).

I'm not yet sure how best to make this happen. If anyone has any ideas please do share. Will be back later...

[trusktr]

Some other things to note are that the current Workspace (souped-up PaneContainer) also contains things like a PackageManager instance, etc, things that we wouldn't want to duplicate. The change needed to make this effective might be to first separate those concerns so that it's possible to have multiple WorkSpaces in the same window without duplicate things (f.e. the package manager).

[trusktr]

Another idea might be to use PaneContainer inside of a tab, so then the UI would become a nested set of PaneContainers (the current commands for splitting panes would work on the focused PaneContainer or Pane). So inside of tabs we could have Panes with more tabs. I still have to get more familiar with the API...

[ghost]

Setting aside whether or not it is a good idea to try and replace Workspace, it doesn't look like it will be easy to do it through a package if you look at how the atom environment is initialized.

You can see here that the PackageManager is created before the Workspace. However, loadPackages is not called until startEditorWindow. By that time, Workspace has already been created and maybe used for several other things.

As far as trying to replace Workspace, that seems like a pretty heavy handed solution since it could potentially cause a lot of breakage for other packages. Maybe it could be done but if there was any other way it would probably be better to avoid it.

[Dmitra]

I'm using this plugin https://github.com/vim-ctrlspace/vim-ctrlspace which makes even more use of panes within a tab. This plugin has a separate on demand pane with list of opened buffers in a tab. Together with ability to rename a tab this gives you even more structure.

Usually I have 6 - 12 tabs opened in VIM, named by project part. And within each tab I have 1-20 buffers (files) attached (opened) while only one or two are simultaneously visible (opened as panes).

While similar structure may be achieved by proper arrangement of files within a project folders, it's much more flexible to have an alternative "folder view" on the project functionality part in the editor.

Unfortunately this plugin is no more maintained and it makes VIM very slow soon.
So, not having panes within a tab is a show-stopper for me to enjoy great Atom infrastructure.

[trusktr]

True, panes within tabs make much organizational sense. If people took the time to learn Vim, then they'd realize how nice organization with panes inside tabs. If Atom took the time to make it, then they'd also realize how powerful it is.

[hoschi]

Also no one explains the ideas behind the concept used in Atom (VS Code, IntelliJ, ...), where I see writeups like @Dmitra why Vims version is better more often. Which are the use cases developers of these editors thought "hey lets do tabs in splits, it makes sense because XYZ"?

[trusktr]

There's a new plugin on the block that adds it's own tab system, so we can have panes inside tabs: https://atom.io/packages/atom-vim-like-tab

If you disable Atom's tab plugin, and use this one instead, you can split panes inside these tabs. It works great! You can, for example, map gt to go to next tab, gT for previous tab. If you close the last pane inside the tab, it closes the tab, just like in Vim! If you have vim-mode-plus installed, then pressing <c-w>c to close the last split will feel just the same.

Atom team, maybe you can adopt this feature, and make it configurable which form to use?

[stale]

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. Because the Atom team treats their issues as their backlog, stale issues are closed. If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of Atom
2. Comment that the issue is still reproducible and include:
   • What version of Atom you reproduced the issue on
   • What OS and version you reproduced the issue on
   • What steps you followed to reproduce the issue

Issues that are labeled as triaged will not be automatically marked as stale.

[lee-dohm]

Thanks everyone for the feedback.

At this point, we don't have any plans to change Atom's view system to enable this scenario. If this is functionality that you need, you may want to check out the atom-vim-like-tab package that @trusktr mentions above.

Thanks again for everyone's input and especially the link to the great community package!

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!