|Extension|Author|Version|
|---|---|---|
|EditorConfig|EditorConfig|0.3.4|
|lorem-ipsum|Tyriar|1.0.0|
|sort-lines|Tyriar|1.1.0|
|theme-glacier|Tyriar|0.0.10|
|vscode-svgviewer|cssho|1.2.0|
|vscode-eslint|dbaeumer|1.1.0|
|tslint|eg2|0.7.1|
|git-project-manager|felipecaputo|1.0.0|
|Theme-Wombat|gerane|0.0.2|
|md-navigate|jrieken|0.0.1|
|vscode-scss|mrmlnc|0.6.0|
|csharp|ms-vscode|1.5.3|
|typescript-javascript-grammar|ms-vscode|0.0.10|
|sass-indented|robinbentley|1.2.1|
|dark-plus-material|vangware|0.1.4|
I'm a heavy user or ctrl+1, 2, 3 to focus the various editors available to me, when there is a tab with multiple editors especially when there is only 1 editor group ctrl+2 feels very strange as it opens a new editor tab. I don't know how to get focus into the default settings editor.
Assigning this to people involved in these split tabs as it's more of a general problem. Maybe I'm just missing something having not used the diff editor. I want a reliable way to focus either editor within a split tab and/or potentially making it more obvious that it's a split editor? If there is already a way to deal with this, is there a better way we could educate users like myself?
I have mine bound to alt + ➡ and alt + ⬅
{
"key": "alt+left",
"command": "workbench.action.focusPreviousGroup"
}
{
"key": "alt+right",
"command": "workbench.action.focusNextGroup"
}
That's from my configs
Works pretty well for me.
@rozzzly that actually highlights the problem. In the latest Insiders this does not work as you may expect intuitively in the settings editor as there are 2 editors in a single editor group.
I like the idea of introducing commands when a side by side editor is opened that allow to navigate between left and right editor inside the split editor 👍
Assigning this to November milestone
Moving to January since this is no urgent
I'd love to be able to bind alt+← and alt+→ to move to the previous next editor regardless of whether it was in the same group. That would replace my reliance on ctrl+num personally.
If you're interested in another reference - A really polished implementation of this is available inside Xcode ( cmd + j ) which also supports navigation between tabs and creation of new helper tabs etc

I think this is also related: https://github.com/Microsoft/vscode/issues/22412
Just to add even more color to this request. I would love this feature for GitLens, so that I could control which pane was focused depending on the command.
For example, alt+, in GitLens opens the a diff with the previous version, so if I could focus the left pane (i.e. previous), you could just keep pressing alt+, to navigate backward. And then I would leave focus on the right pane when navigating forwards alt+. to allow that smooth navigation as well.
But right now, since the right pane is always focused, the forward navigation works, but the backward navigation requires you to press alt+,, focus the left pane, rinse repeat :)
Thanks!
Vim has its own diff feature (vimdiff or :diffthis) and it can be navigated to left by Ctrl+w Ctrl+h or right by Ctrl+w Ctrl+l. But currently VSCodeVim won't work as such, Ctrl+w Ctrl+h will skip to sidebar.
FYI I solved this problem recently for myself with help from @roblourens, now I just open the right settings pane with this setting:
"workbench.settings.openDefaultSettings": false
I then have these keybindings if I want to search all settings:
{ "key": "shift+cmd+,", "command": "workbench.action.openRawDefaultSettings" },
{ "key": "shift+ctrl+,", "command": "workbench.action.openRawDefaultSettings" }
This seems to be really counterintuitive. You'd expect to be able to move between the two panes easily when editing settings. Is the new settings editor being prioritized instead of supporting this? Even just opening the user settings file and raw default settings file in two split workgroups would be much more intuitive than the current default, which in addition to this problem also looks very cramped.
Thank for the solution, @Tyriar. It suffices for now.
This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding and happy coding!
Most helpful comment
FYI I solved this problem recently for myself with help from @roblourens, now I just open the right settings pane with this setting:
I then have these keybindings if I want to search all settings: