Allow for empty editor panes

[sarbbottam]

Is there a way to configure VSCode, so that it always shows a fixed number of pane? Or keep the pane even when there is no open file.

Something like

[bpasero]

Currently not.

[ykka]

Oh I beg you, let's allow it!

Use cases:

• sometimes you just want to click into an empty pane and open some file there. Duplicating your currently open file just to open another one in a new pane (correct me if I am missing some shortcut), is a bit pointless. Worse, it leaves you with many editor instances of the same file.
• sometimes you just want to keep it split into three columns visually - for some it's a matter of harmony, symmetry. For me the dynamic behaviour of all the editor panes feels a bit messy for example. Their width changes all the time.
• sometimes I just want to keep some information and discard it once I am done. It'd cool if I could have empty pane, hit cmd+n and paste stuff there.

Yes, I come from Sublime but that IMO has been one of the features that created the feeling of simplicity. The way you split your editor - it stays this way.

[jasonlemay]

I've recently switched from Sublime to VSCode, and it's the only missing feature that is bothering me on a daily basis.

[ttbarnes]

+1. Also currently when you open a new pane, it duplicates the file in the original pane. To work on a new file in a new pane, you have to close the duplicate file opened in the new pane, before opening a new file in the new pane.

[cranesandcaff]

Is this something that could be added with an extension?

[darraes]

This is really bothering me as well.

[aubreypwd]

+1

[albert-olive]

+1

[emyller]

That and #16858 (comment) would be awesome.

[aaronbushnell]

It'd be nice to have this functionality natively, but here's a temporary, hack-y and untested solution for the short term!

1. Install the Macros extension to allow you to map keyboard shortcuts to a sequence of commands.
2. Add the following JSON to your settings.json file:

"macros": {
  "splitPane": [
    "workbench.action.splitEditor",
    "workbench.action.files.newUntitledFile",
    "workbench.action.moveEditorLeftInGroup",
    "workbench.action.closeEditorsToTheRight"
  ]
}

3. Add the following JSON to your keybindings.json file:

[
  {
    "key": "cmd+alt+2",
    "command": "macros.splitPane",
    "when": "editorTextFocus"
  }
]

Now when you use the cmd+alt+2 shortcut, VS Code will split the editor, create a new file, move this file to the first position in the group and close the other file in the split.

There might be a more efficient way to do this, but this was a quick test to see if it would work at all.

[ivanbanov]

@aaronbushnell It works, thanks

[mehulkar]

Also a Sublime -> VSCode convert and trying to get used to it. A typical workflow for me is to:

1. open VSCode
2. Open File1
3. Split pane
4. Open File2

Right now, the only way I know of to do this is to:

1. Open VSCode
2. Open File1
3. ⌘+/ to open File1 again in the second split
4. ⌘+P to find and open File2
5. ⌘+Shift+Tab to go back to the second File1
6. Close File1

The most surprising thing about this is that ⌘+/ opens the same file again in the second split. I'm not sure why I would ever want the same file open twice?

[SavePointSam]

Waiting on this to be fixed before I can switch to Code over Atom.

[johndugan]

As a dev floating between Sublime and Code, this is the biggest downfall of Code at the moment.

In addition to the new pane's initial state being empty when triggered, multiple keyboard shortcuts should be allowed (alt+shift+1 = 1 pane, alt+shift+2 = 2 panes, etc.), and when keyboard shortcuts are triggered they should reset (evenly distribute) the horizontal space.

[rkpatel33]

+1

[simonvomeyser]

+1

[pratuat]

+1

[johndugan]

Curious if @bpasero could give us an update on this issue?

[willsoto]

@bpasero I'd be interested in taking a stab at this, if you think it's feasible. I just need to be pointed in the right direction.

[bpasero]

@willsoto thanks for your help but in this case I would stay away from a PR because this area will get a rewrite for the planned grid layout feature. I was planning to tackle this as part of the grid layout.

[alexburner]

@bpasero grid layout sounds exciting! Any public plans/details you could link us to?

[daniel-hubdoc]

+1

[AndreasBackx]

@bpasero is there an ETA for the grid layout feature?

[bpasero]

@AndreasBackx yes, June. See #49599 (comment)

[ttbarnes]

@bpasero Thank you, looks great! I'm interested what the keybindings will be like?

[bpasero]

@ttbarnes for what action specifically?

[ttbarnes]

@bpasero EG splitting into 2/3 horizontal columns?

[bpasero]

@ttbarnes still the same keybinding as before. we support splitting of editors independent from this issue.

[AndreasBackx]

@bpasero thank you very much for the update. What is the new behaviour when splitting a view? Currently when you split the view, it opens the current file twice which more often than not you never really need. If this remains the same, is there a possibility into making this configurable?

[bpasero]

@AndreasBackx with the new grid work it will show an empty editor group instead of opening an editor.

[AndreasBackx]

@bpasero sweet, I'll check it out on the Insiders build once it's available and when I can find the time between my finals. Thank you once again for the PR!

[bpasero]

This landed as part of #14909. A setting workbench.editor.closeEmptyGroups allows to configure if closing the last editor of a group should also close the group.

While this feature will land into our insider builds only sometime next week (for a stable release end of June), we have custom insider builds for testing this feature now available for more people to try out:

• macOS: Download
• Windows: Download
• Linux: Download

Note: In order to run these builds you will first have to close any running VSCode Insiders build.

Feedback is very welcome, ideally as individual issues and not as comments here to reduce the number of notifications for people subscribed. Please ensure to first have looked for any existing issue with the workbench-grid label already: query

[alexburner]

Sorry this is basically a +1 comment but YESSSSS SO EXCITED! Thanks @bpasero !

[that70schris]

this is so close to being so perfect, only thing left for me is to disallow closing of an already empty group using the close keyboard shortcut (command+W). If I want to close a group I want the only option to do so to be clicking the x in the upper right hand corner, or possibly a different shortcut.

[bpasero]

@that70schris easy, just add this to keybindings:

{
	"key": "cmd+w",
	"command": "-workbench.action.closeGroup",
	"when": "activeEditorGroupEmpty && multipleEditorGroups"
}

[karlhorky]

Thanks @bpasero! Maybe that should be documented more prominently in the grid editor layout docs themselves? Seems like something that more people would want to set... Or maybe it's even relevant enough to be default when workbench.editor.closeEmptyGroups is set to false?

[that70schris]

awesome! @bpasero thanks!

[a13o]

I close my tabs using middle click, and unfortunately it doesn't respect the workbench.editor.closeEmptyGroups. There's no way to rebind mouse buttons either, so no workaround via keybindings.

I think @that70schris is correct and setting the workbench.editor.closeEmptyGroups flag to false should be enforced consistently across all ways to close a tab.

Great feature, otherwise! This was the one thing missing from vscode for me