Open Neutrino-Sunset opened 7 years ago
I found the discussion about enhancing the editor group functionality here
https://github.com/Microsoft/vscode/issues/5911
...and added some thoughts of my own about how grouping and splitting should be two separate things which it might be useful to reiterate here.
My personal workflow is to open editors horizontally (side by side). Occasionally I may want to view two parts of the same file, which I do by splitting that editor vertically (one pane above the other). Splitting the file in the editor (as opposed to opening another vertical editor group) is a distinct useful feature because splitting one editor vertically does not half the height of all the other horizontally laid out editors you have open.
Suggesting that opening additional horizontal or vertical editor groups performs the same job as editor splitting is to completely misunderstand the problem. Suppose I have 4 editors laid out side by side and I want to split one editor vertically. If to do this open my file in another editor in a group below the existing editor group, then all the other editors in the first group are now halved in height.
This is why editor groups and editor splitting are two different things.
+1 Horizontal splitting is a really frustrating experience in vscode. And apart from git diffing, it ends up being more of an annoyance (misclick) than an actual feature.
Sent from my Samsung SM-A500H using FastHub
+1 This is the only reason why I'm unable to switch from vim to vscode. The idea is that you want to be able to split a tab, not the entire editor. For example, I want one tab vertically split with index.html and controllers.js, and another tab split between directives.js and somethingelse.whateva.
This workflow would make sense to me as well. I work in Vim the same way that robertocarla describes. I like to work with implementation and tests side by side, and switch tabs to switch to a different implementation/test pair.
It's also disruptive opening a git diff when you have got a split view open, as the diff opens in one side of the split only, but splits it in half again. Ideally, opening a git diff would open a new tab (a blank canvas with no splits), splitting that in two vertically.
There are some other (now closed) issues not referenced here that are requesting the same feature, just to indicate that there is a healthy demand for this: https://github.com/Microsoft/vscode/issues/7418 https://github.com/Microsoft/vscode/issues/49062 https://github.com/Microsoft/vscode/issues/41486
I fully agree the description in this ticket. The current "split" functionality imposes a reduction of edition area to all other editors. This is not an editor split but a layout split. I vote +1 for a real editor split feature
Vim-style splitting would be awesome! This is the cause of one of the few remaining efficiency decreases I get by switching to VSCode from Vim
+1 for this, also a feature I'd like to see. I think there's quite a few users trying to migrate off vim that use this workflow!
Trying to migrate from Webstorm, and this sucks.
In SQL Server Management Studio and Textpad, I often like to split a single tab into two views, one on top of the other, so I can see two sections of a file in the same tab. It's very convenient for keeping the important parts of the code right in front of my eyes. And just to be clear, when I click to a different tab, the whole of the previous tab (with both views) hides behind the new tab. I don't want to have two tabs for the same file, where the second tab is still visible even after I click to a different tab. (Hope that makes sense.) Would definitely appreciate this.
Any news here?
@bpasero What is the status of this feature request? Has it been added to any roadmaps or backlogs? I think the duplicates and thumbs up indicate a pretty healthy demand.
@Hubro it is on the Backlog:
As for indicating "healthy" demand, this issue is currently at position ~250 in terms of upvotes based on this list:
https://github.com/microsoft/vscode/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc
So I would argue, 250 issues have more demand compared to this one (if you count upvotes as a sign for demand). As such, it may stay on the Backlog for a longer period or even forever.
Perhaps it would help to have some color on whether this is a limitation of electron, or if there are other architectural challenges to making this happen. For instance, I noticed in the discussion on custom editors / webviews there was mention of
Non-goals ... Embedding of VS Code's text editor in webviews
Is that a possible solution, or am I completely barking up the wrong tree? Would be nice to get a feel for how this might relate to other items on the UI roadmap (e.g. detachable terminals and editors), or maybe some pointers for community solutions (extensions or PR attempts). Thanks.
This is a huge blocker for me to comfortably move from vim to vscode.
I find it very cumbersome to write C++ without this feature. Having a separate vim tab for each pair of .h/.cpp files I'm working on (split vertically) is incredibly useful, as opposed to having a single split and manually swapping out the files in each view every time I want to look at a different class. Even in languages which don't have separate interface/implementation files, having related files (such as code and test) stay open together is very useful. Personally I've found working with splits in VS Code so unmanageable that I just tend to not use them at all.
@bpasero Can you please edit https://github.com/microsoft/vscode/issues/41486 to link to the duplicate issue? It is the top result on Google (for me at least, Google probably knows me too well) with no obvious link to this duplicate (issue mentions aren't as obvious). An actual comment will help.
For example, I want one tab vertically split with index.html and controllers.js, and another tab split between directives.js and somethingelse.whateva.
Yes!!!
People that haven't used Vim (or soe other text editor with vim-like splits) just have no idea what great improvement in UX and workflow they are missing.
Having markdown on one side, and a markdown live preview on the other, all inside the same tab, would be very useful. Every tab could, for example, be for a single markdown file, each with their code and their live preview.
By the way, there's a new VS Code extension called Neo Vim
that integrates Neovim (a Vim fork with an RPC API for GUIs and IDEs) into VS Code so that key combos and text editing can be handled natively by Neovim as the backend (or think of it as Neovim with VS Code as a GUI).
This window splitting feature would be super useful for that Neo Vim extension so that it can map the same concept (same key combos) from neovim's equivalent to VS Code's equivalent. It would be GREAT!
I bet we'd see an sudden influx of vim/neovim users into VS Code, beside the introduction of Neo Vim
.
For more on Neovim in VS Code (or Neovim with VS Code as a GUI), see
https://www.reddit.com/r/vimporn/comments/ki00pj/neovim_with_official_github_dark_theme/
^ I linked two new issues that would pair very nicely with this one.
People that haven't used Vim (or soe other text editor with vim-like splits) just have no idea what great improvement in UX and workflow they are missing.
1000% this.
I am still struggling to understand how anyone who writes code everyday in VSCode isn't also begging for this feature. Seriously, try the splits in VIM for a single day and you will quickly understand how game-changing and vastly more efficient that workflow is over having splits outside of tabs.
I literally check this issue (and the duplicates that constantly spring up) annually to see if any progress has been made, as this is the only blocker to me transitioning over to VSCode to take advantage of all the other features that VIM doesn't have.
Not only just splitting the same file. We often work with related files, like html&js pair, cpp & header pair... And different files have different related files, currently we have to switch/open them manually every time.
I think a simple implementation is add an option to remember current split layout, and simply show/hide the split-ed tabs in layout when switching to tabs of different "split group". Not perfect, but better.
Now that the ability to display terminals in the editor has been implemented,I think that the need for "VIM-style tab splitting" will become more and more important. It would be a great gift for Linux CLI users to be able to use the terminal splitting feature like Hyper, Terminator, and Tilix.
In my case, I use "Remote SSH" to connect to my research server for development. In order to analyze logs and compile, I need the Linux CLI very much. I would be very happy if I could do this only with VSCode, without using any other terminal emulator.
I vote +1 for this great feature!
Here is a set of keybinding which changes the behavior from ctrl+tab to share editors between split (it uses the history instead of the opened tab in the current split). It feels close to switching between vim buffers.
[
{
"key": "ctrl+tab",
"command": "workbench.action.openPreviousEditorFromHistory",
"when": "!inQuickOpen"
},
{
"key": "ctrl+tab",
"command": "workbench.action.quickOpenNavigateNextInEditorPicker",
"when": "inQuickOpen && inFilesPicker"
},
{
"key": "ctrl+shift+tab",
"command": "workbench.action.quickOpenNavigatePreviousInEditorPicker",
"when": "inQuickOpen && inFilesPicker"
}
]
You can also hide the tab bar by using this setting:
"workbench.editor.showTabs": false,
So I had to switch from VIM to VS Code and got frustrated enough by the lack of this capability that I built an extension to solve it. Give it a shot and let me know if it helps, I use it pretty much every day now.
https://marketplace.visualstudio.com/items?itemName=agquick.workviews
The "workviews" show up in your Explorer tab and are basically "named" tab/file groups that are easy to switch between. It's somewhat limited because for some strange reason VS Code doesn't allow me to directly access all open editors, but it's better than nothing, and feels almost like VIM again.
Pushed a change to enable text based editors to split/join:
Also added commands to move keyboard focus between left and right side.
Commands:
workbench.action.splitEditorInGroup
workbench.action.joinEditorInGroup
workbench.action.toggleSplitEditorInGroup
workbench.action.focusLeftSideEditor
workbench.action.focusRightSideEditor
workbench.action.focusOtherSideEditor
Still investigating whether vertical & horizontal splitting should both be supported or whether that could be a separate feature request to follow up later.
Vertical splitting is more important as monitors are rather wide than high. More monitors mean also more width than height.
For my use-case, horizontal splitting is actually more important.
I commonly split VS Code into two vertical groups, each with a few editor tabs. Then sometimes one of those editor tabs contains a very long file to which I need to make edits in multiple places. I'd like to spit that tab horizontally, while keeping the other tabs within that group tall.
For me, the most important use cases are to review two files side-by-side, but grouped, e.g. for C++, having one tab with foo.h
and foo.cpp
, and another tab with bar.h
and bar.cpp
, so I can switch quickly.
For horizontal screen space management folds exist already, for vertical there is nothing at the moment. Which doesn't mean that horizontal splits are not important as well.
To clarify on the changes I pushed: this is limited to the same file as requested by the OP. If you want to see 2 different files in the same editor group, please consider to file a new feature request. It is not impossible to even allow any other file to show to the side (or even something completely different like a live preview of HTML) but I think we should keep the feature that was originally requested as it is.
First of all, thanks for the work and progress!
I might be wrong, but my guess is that the majority of people in this thread were hoping for full "vim-like" tabs, rather than only a split the view same file, which is rather limiting - indeed many of the closed duplicates such as Window splits inside a tab #104483 and Window splits inside a tab. #41486 did not imply that same-file splitting would be sufficient.
We could open a new issue, but I think that would unfortunately "reset the clock" in both time and upvotes on this long-desired feature.
Understood and it's in the cards, at least for simple scenarios of 2 files (either vertically or horizontally split).
I would think that we would not go down the path of allowing a full grid layout within an editor tab just because of how complex that would become in terms of managing editors.
Since we already have this side-by-side functionality in a way for a long time when you just diff 2 files, expanding it to what I pushed now seems natural and manageable.
Understood and it's in the cards, at least for simple scenarios of 2 files (either vertically or horizontally split).
Please make sure that this feature is accessible via a keyboard shortcut from Quick Open
, like how ctrl-enter
currently opens it into a side-by-side editor.
Thanks!
workbench.action.splitEditorInGroup
and workbench.action.toggleSplitEditorInGroup
can split workbench.action.toggleSplitEditorInGroup
showed, but no use when execute workbench.action.toggleSplitEditorInGroup
@heartacker can you report issues you find with the implementation into new issues, then we can discuss there. I am not sure I can follow all the things you mentioned.
Oh nevermind, I see the issue with Ctrl+W
not working and fixed it already earlier today. I also added a toggle action to flip vertical/horizontal layout. This is driven by a new setting workbench.editor.splitInGroupLayout
:
Will be available in tomorrow's insider build.
@bpasero thanks for your update and there are some purpose about splitEditor.
toggleSplitEditorInGroup
, I tend to use ctrl+alt+\,like ctrl+\toggleSplitEditorInGroup
to convert for better experience, no split
-->split horizontal
-->split vertical
--> no split
. After that we could use one command or shortcut to toggle each statemaybe we could make the split line more visible
@heartacker
that keybinding is very frequently used already in other places, the only "free" one I found that I can use is a key-chord of: CtrlCmd+K, CtrlCmd+Shift+US_BACKSLASH
that is the reason why this is a setting, assuming you only want to configure this once. once you flipped the layout, all other split editors will use it
that color is themeable either when you change editorGroup.border
or sideBySideEditor.border
(the latter I just pushed today and will be available tomorrow)
Reading through the comments and linked issues, it looks like the original intent of just splitting 1 editor into 2 is not what got all the upvotes. Instead, it seems that some are asking for being able to open 2 different editors in the same group (also in https://github.com/microsoft/vscode/issues/22068) and others want to open as many editors as they want side by side in a group ("VIM Style Tabs").
I feel that being able to open any 2 editors side by side in a group is realistic. Being able to have a full grid of editors within a group is imho rather unrealistic for the complexity this brings and given we have full grid support via groups already.
As such I have extracted https://github.com/microsoft/vscode/issues/132651 for the work I am planning to do in September or what is already pushed with regards to being able to split an editor into 2.
open setting config with split view, then use ctrl+kctrl+shift+\and the split view is closed into one, but trigger that again, we couldn't recover the split setting view,
click setting file will create new-two-tab-view even opened
@heartacker if you see any issues specific to settings, please report as new issues and make sure to try this out in insiders. You can give our preview releases a try from: https://code.visualstudio.com/insiders/
I hope this feature can also be used when we move the terminal to the editor area.
@bpasero Hi. Is the split an editor without creating a new group feature available for plugins? Can a plugin use this feature for creating own UI inside a splited tab?
There is no official API, though arguably an extension could open an editor and then trigger the workbench.action.splitEditorInGroup
command right after.
Reading through the comments and linked issues, it looks like the original intent of just splitting 1 editor into 2 is not what got all the upvotes. Instead, it seems that some are asking for being able to open 2 different editors in the same group (also in #22068) and others want to open as many editors as they want side by side in a group ("VIM Style Tabs").
I feel that being able to open any 2 editors side by side in a group is realistic. Being able to have a full grid of editors within a group is imho rather unrealistic for the complexity this brings and given we have full grid support via groups already.
As such I have extracted #132651 for the work I am planning to do in September or what is already pushed with regards to being able to split an editor into 2.
I'm a little confused, is this being dropped? The issue title changed to something different, and I can't find the original ask tracked somewhere else.
But just to recap, because this issue is getting huge and confusing to me:
For most vim users, this is an intrinsic part of the workflow for stuff like having an impl/test side-by-side, and maybe you open a third split for like, an HTML template or stylesheet.
Then, those 3 splits are grouped together in one tab. So when I want to think about "ComponentX", I just navigate to that tab and see everything at once. Maybe even a 4th split for documentation.
I think multiple editors solves all of this, but the missing piece is grouping them into a single tab.
One way to solve this might be to introduce an optional, higher-order tab bar where each tab groups editor splits, and then provide an option to disable the tab bar inside the editors.
But anyway, I understand that's probably a lot of effort. I hope the original feature request is still tracked somewhere, though.
it seems that some are asking for being able to open 2 different editors in the same group
I think this is something that would be really useful, especially if it could be controlled via an extension.
For example, we often use two editor groups for doing side-by-side previews (eg markdown). But that is usually no what is wanted as when you click onto another editor tab, the preview is still taking up half the screen.
It would be great if extensions could split an editor in half, and then put a webview into the other half.
Very hacky demo:
It definitely feels like the Code team prefers this functionality be implemented as an extension, and this is pretty much exactly what my extension "Workviews" (https://marketplace.visualstudio.com/items?itemName=agquick.workviews) does, except the "tabs" are shown in the Explorer pane on the left.
The problem is I can't get access to all the open editors/terminals/etc properly until VS Code decides to open up the extension APIs a bit. But it's the closest feeling to VIM I've been able to achieve thus far.
VsCode has the ability to horizonatally split an editor window. When you execute
code --diff file1 file2
both files are opened side by side in a single editor window with a single header tab. A similar view is presented when you edit the VsCode settings.This is splitting. It would be nice to be able to do this for my own files to have multiple views of the same file. What would make it actually usable would be the following three enhancements.
What we currently have is a keyboard shortcut "workbench.action.splitEditor" which doesn't actually split an editor at all, instead it just opens the same file in another editor in a different editor group. This is not editor splitting which by definition should occur in the same editor tab.
Calling opening a file in another editor group 'splitting' when there is already nascent functionality to support proper splitting is a pointless ambiguity that serves only to reduce the possibility that the editor will ever support proper splitting any time in the near future.
Proposal: