Spyder: Shortcut to switch between screens in split-screen mode

[dan-ai-rgus]

Problem Description

I cannot find a keyboard shortcut that will allow me to switch between screens of code in split-screen mode. So if I am in split-screen horizontal mode and I see file1.py on the left and file2.py on the right, I would like to have a keyboard shortcut to switch focus between file1 to be able to edit file2 without using the mouse. Is this possible??

Versions

• Spyder version: 3.3.1
• Python version: 3.6.6
• Qt version: 5.6.2
• PyQt version: 5.6
• Operating System name/version: Windows 10 Pro

[goanpeca]

I do not think this is possible at the moment but we should definitely add something.

On mac a "common" way is to use Cmd+1, Cmd+2 etc...

Thoughts @ccordoba12 @jnsebgosselin @impact27 @CAM-Gerlach ?

[impact27]

Shouldn't Cmd+1, Cmd+2 be for tabs?

[dan-ai-rgus]

In Windows switching tabs is typically done with Ctrl+Tab, and this works in Spyder too. However, this lets you cycle through tabs but within the _same_ screen. I was hoping there was a way to go from left screen to right screen etc. in split screen mode.

[ccordoba12]

I think this makes little sense: how should we cycle among split editor panes? Left to right and then top to bottom? Or the other way around? No one would be pleased and some would find it courter-intuitive.

So I'd say we should close this as "Won't fix".

[goanpeca]

I think this makes little sense: how should we cycle among split editor panes?

Cycling in order of creation.

Command numbers on is what vscode provides. I believe it is a real issue that needs fixing.

[ccordoba12]

Ok, but IMHO we have way more important things to fix, so I'd say we should move this to our "Wishlist" milestone in any case.

[CAM-Gerlach]

This would be very handy, saving a lot of time when switching between files, and is important for keyboard-only accessibility. It isn't quite as simple as it might initially appear since Spyder can have arbitrary numbers of split panes, split multiple ways, so we need to have some defined order (ideally, MRU order) to switch between them in, which would be a simpler implementation than using some arbitrary mapping of Ctrl-Numbers. For the most common case and the one that @dan-ai-rgus is asking about, a two-way split pane, the order doesn't actually matter, it can be whatever order the list of EditorStacks is already in. What about CtrlAltTab and CtrlAltShiftTab (replacing Ctrl/Alt with Cmd/Option on the Mac)?

[dan-ai-rgus]

Thanks for the thoughtful and prompt consideration to this issue!

@ccordoba12 I agree that if you consider cycling automatically through every tab in every screen separately this could get out of hand.

@CAM-Gerlach because of @ccordoba12 concern of it being counter-intuitive to cycle (and I agree), perhaps we can split the problem into two: (1) addressing panes individually (new functionality) and (2) switching between tabs within a pane (existing functionality).

So, each pane would be assigned a number in some order (maybe via MRU, or left to right then top to bottom) and when I press ctrl+alt+[number/letter] I go to that pane.
Then within a pane there is existing functionality to switch tabs, solving the issue completely. If you want to get fancy with it, you can make a popup with the pane's number next to it when pressing ctrl+alt.

[CAM-Gerlach]

@dan-ai-rgus I'm not sure I understand what you are proposing (or recommending against) here. As I understood it, your original request and the followup discussion has only been about switching between panes, and you even mentioned that Spyder already fully supports tab switching. I'm certainly not suggesting that Spyder make any fundamental changes around including tabs from other panes in the tab switcher, at least not as part of an initial implementation of this feature as you propose here.

My suggestion was developed explicitly with @ccordoba12 's concerns in mind to reduce the complexity of the UX and implementation of this as much as practicable. Adding in the additional components of managing 10 different shortcuts, assigning them to panes, having to order them consistently and providing some clear means of indicating which pane is which so the user can navigate to them is strictly more complex than what I proposed, while also being more complicated UX wise.

Namely, I suggested just allowing the user to simply cycle to the next and previous editorstacks with standard, expected shortcuts in some arbitrary order (ideally just the existing order they are in the list of editorstacks, which I presume is based on open order or similar). This would handle the most common cases (1-3 panes) with one keystroke and could always be improved later (e.g. add MRU or other ordering).

[dan-ai-rgus]

If you make a list of all the pane and let me cycle through them, that would be sufficient. A specific example:
I usually have open: (1) file explorer (2) find in files (3) interpreter (4) 7 tabs of code in split view 1 (5) 7 tabs of code in split view 2

If I can switch between these numbered panes, in any order really, as in my example (and then use existing shortcuts to cycle through my 7 tabs of code) that would address this issue completely. Does this make sense? I didn't mean to add complexity to this, merely suggesting how to make this potentially more user friendly (i.e., without imposing an order). Thanks again!

[goanpeca]

@dan-ai-rgus I think you are mixing too many things.

Panes already have shortcuts:

So that is a completely separate discussion

This issue is about split panels within the Editor pane.

[dan-ai-rgus]

You are right. I am not familiar with all the terms so my apologies and the other comments confused me. (though, I notice that when I am in split screen mode, using the shortcut to move from editor to interpreter does not work, but that is a separate issue).

I am speaking specifically about the editor pane, in split screen view. If there is a way to cycle through the split views (in any order...) that would be great.

[goanpeca]

I am speaking specifically about the editor pane, in split screen view. If there is a way to cycle through the split views (in any order...) that would be great.

Will try to address this :-)

[CAM-Gerlach]

Even though I myself had been big on standardizing and using consistent terminology for Spyder's UI and documentation, I've inadvertently made that conflation myself still.

[bcolsen]

@goanpeca said:

Panes already have shortcuts

I think it would be pretty intuitive to use the editor pane shortcut (ctrl+shilf+E..strangely not listed in the pane menu) to switch between editor sub-panes. As far as I can see it currently does nothing when you are already on the editor pane.

[CAM-Gerlach]

That could work, I guess. It only goes in one direction, and when triggered when the Editor is not active, it would need to work as it does now, going to the last active editor panel, so its probably more a little more complex/error-prone to implement. The major advantage is discoverability, especially if a significant number of users already use the switch to editor shortcut (otherwise, it would have to be given its own menu item to be visible in the UI at all).

strangely not listed in the pane menu

I always remap it (along with the other 4 main panes) to Alt-1 (2-5 for the others) so they are actually usable to quickly switch panes, but even when remapped its not visible. I would guess its just an oversight in the menu item creation.

[dan-ai-rgus]

Thanks again for your attention to this.

For what it's worth, I found that if I put the editor in split screen mode and then pop out one of the split screens, I can switch between them using alt-tab. Not as convenient, of course, but a sufficiently good solution.

[CAM-Gerlach]

Thanks, and glad you found something that works for you.

As that breaks a lot of workflows since it requires a quarter of a second screen, or half the current screen to tile it into a standard window layout, as opposed to be able to do so flexibly within the existing Spyder interface, its not really a viable long term solution to this deficiency IMO.

[dan-ai-rgus]

@CAM-Gerlach totally agree with both deficiencies stated.