Vscode: Allow for empty editor panes

Created on 6 Feb 2016  Â·  53Comments  Â·  Source: microsoft/vscode

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
screen shot 2016-02-05 at 6 31 53 pm

feature-request on-testplan workbench-editor-grid

Most helpful comment

+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.

All 53 comments

Currently not.

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.

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

+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.

Is this something that could be added with an extension?

This is really bothering me as well.

+1

+1

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"
  ]
}
  1. 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.

screen recording 2017-06-17 at 02 32 pm

@aaronbushnell It works, thanks

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?

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

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.

+1

+1

+1

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

+1

+1

I agree with all these comments, we have a strict 80-col limit at work and I have a nice i3 window setup with my text editor locked into a size for 3 coding panes.

But I keep accidentally losing these panes when I close the last file in one, or drag the last file to another pane, and then I gotta go through the whole song & dance to get them arranged again.

It's one of those minor issues that feels like a major issue.

+1

+1

+1 The current behaviour is just bizarre. I always have split pane open on wide screens, there is no point where I want it off or to duplicate the file I'm already viewing

+1

+1 this behaviour is easily the worst thing about VScode.

Pro-tip: if you command-click on a file in the navigator or press command-enter in one of the Go to... palettes, the file will open in a new tab by itself or append itself to the next rightmost tab.

+1

@bpasero any update on this issue?

Please stop aimlessly adding +1 comments. Just thumbs up the first post or even this post. I care a lot about this issue and am frustrated about updates that aren't anything of merit to the issue.

If you want updates, just click the subscribe button at the bottom of the right-hand column at the top of the page.

+1 to SavePointSam's post

CMD + "Enter" opens a file from quicksearch in a new pane.

For anyone else who is watching this issue.

I liked @aaronbushnell 's method but I am not usually trying to start new files.

I hope I'm not spamming people's inbox with obvious information

CMD + Control + (left / right) will move your current file into the adjacent pane.

If you are on just 1 pane and use (CMD CONTROL RIGHT) it will open a pane, and put that file there.

If you are on 2 panes and use it again, it will create a third.

Between this and CMD + Enter the lack of empty panes has gotten a lot easier to deal with.

@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.

@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.

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

+1

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

@AndreasBackx yes, June. See https://github.com/Microsoft/vscode/pull/49599#issue-187115615

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

@ttbarnes for what action specifically?

@bpasero EG splitting into 2/3 horizontal columns?

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

@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?

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

@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!

This landed as part of https://github.com/Microsoft/vscode/issues/14909. A setting workbench.editor.closeEmptyGroups allows to configure if closing the last editor of a group should also close the group.

image

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:

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

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

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.

@that70schris easy, just add this to keybindings:

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

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?

awesome! @bpasero thanks!

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

Was this page helpful?
0 / 5 - 0 ratings