travel_to_pane should be symmetrical

[adzenith]

In a three-pane layout like this:

+--------+
|    |   |
|    +---+
|    |   |
+--------+

if you're in the bottom-right pane, and move left, then move right again, you'll be in the upper-right pane. Theoretically this should be a reversible movement (but what happens if you're in a seven-pane layout, and move all the way left from the rightmost column? do we have to keep track of every motion made in a direction?)

[kl0tl]

If I understood your example correctly you should go back to the pane at your right and in the correct row each time you move right. If that's so, keeping track of every movement (+ the pane it came from) with a stack should do the trick and work regardless how nested the layout is.

[adzenith]

Yeah, I think a stack would work just fine. I was just trying to think of how deep the stack needs to be. Would we need a stack for every movement you've ever done? I think we could only clear the stack if the layout changed, and pop elements if you went the opposite direction of the top element.

[FichteFoll]

I think you only need to track for each pane which pane you came from when moving on from one side, which will then be the pane to move to for each side. That means 4*n entries, where n is the number of panes.

[adzenith]

Say it's the seven-pane layout:

+-----------+
|   |   |   |
|   |   +---+
|   |   |   |
|   +-------+
|   |   |   |
|   |   +---+
|   |   |   |
+-----------+

Starting in the lower-right, say you move left, then up, then right, then down twice (to the third pane down in the right column), then left. You're now in the bottom of the middle column. Now if you move right, you should be second from the bottom in the right-most column. But if you move up twice, then left, then down, then right, should you end up in the third column down? or the fourth? I.e., could you unwind the whole motion?

[adzenith]

And what if on the way back you only go up once instead of twice, but still end up in the correct pane when moving left?

[FichteFoll]

With my idea, you would end up in pane 6, because you moved from 6 to 5 in step 6. (so the last time you moved to 5 from the right side was from 6)

+-----------+
|   |   | 3 |
|   | 2 +---+
|   |   | 4 |
| 1 +-------+
|   |   | 6 |
|   | 5 +---+
|   |   | 7 |
+-----------+

[FichteFoll]

For clarification:

1. 7 left 5
2. 5 up 2
3. 2 right 3
4. 3 down 4
5. 4 down 6
6. 6 left 5 (replaces record from 1.)
7. 5 right 6 (determined by 6.)
8. 6 up 4 (determined by 5.)
9. 4 up 3 (determined by 4.)
10. 3 left 2 (determined by 3.)
11. 2 down 5 (determined by 2.)
12. 5 right 6 (determined by 6.)

Storage table after step 11 (and 12 too since it doesn't change):

1: {}
2: {"right": 3, "down": 5}
3: {"left": 2, "down": 4}
4: {"up": 3, "down": 6}
5: {"up": 2, "right": 6}
6: {"up": 4, "left": 5}
7: {}

[adzenith]

Yeah, I'm just wondering which one is more intuitive. Should it be the last time you came from that direction, or should you be able to "unwind" your movements in a way?

[kl0tl]

I find more it makes more sense to end up in pane 7, as with the stack based solution. It would also be trivial to add a command to revert the n last movements with a stack.

[mrsean2k]

My reference for this is the venerable Brief - (http://www.briefeditor.com/index.htm) - ancient but never bettered for split pane window management.

The "natural" behaviour I'd find most intuitive is movement based on proximity.

In @adzenith 's first diagram, reproduced below, if I start out in C and move left to A, moving right again will move to B or C depending on my current vertical cursor position in A:

Start at C            Move left to A                            


+-----+-------+       +-----+-------+                      
|A    |  B    |       |A    |  B    |                      
|     |       |       |     |       |                      
|     |       |       |     |       |                      
|     |       |       |     |       |                      
|     |       |       |     |       |                      
|     +-------+       |     +-------+                      
|     |  C    |       |     |  C    |                      
|     |       |       |     |       |                      
|     |     * |       |  *  |       |                      
|     |       |       |     |       |                      
|     |       |       |     |       |                      
+-----+-------+       +-----+-------+                      

THEN

Scroll down           Scroll up                            
then right to C       then right to B                      

+-----+-------+       +-----+-------+                      
|A    |  B    |       |A    |  B  * |                      
|     |       |       |     |       |                      
|     |       |       |     |       |                      
|     |       |       |     |       |                      
|     |       |  OR   |     |       |                      
|     +-------+       |     +-------+                      
|     |  C    |       |     |  C    |                      
|     |       |       |     |       |                      
|     |       |       |     |       |                      
|     |       |       |     |       |                      
|     |     * |       |     |       |                      
+-----+-------+       +-----+-------+                      

If the cursor is at a split, arbitrarily (but consistently) pick the top / left choice

For a stack based solution, I'd handle it like the unwinding of a browsing history stack; if I've hopped around a few panes, assume it's a detour from the pane I started from and I want to return to that pane to continue my main thread of work, so a single key unwinds back through the stack of panes + cursor position visited.

One difference between this and a browser's history stack is that if at any point I visit a pane I've already been to, I'd reset the stack back to that point. So if I visit A->B->C->D->E->C, my rewind stack would be set to A->B->C

A 3rd option presents itself, adopting the strategy used by the WM Slate on OSX; movement between windows can be instigated with a hotkey. When the hotkey is pressed, small icons with a single letter attached appear over the visible windows and over the top of any windows obscured by other windows. Pressing the letter then brings that window forwards and gives it focus.

So every window on the current workspace is two keystrokes away, irrespective of visibility.

For Sublime, this would be simplified by showing a single char overlay at the top right of each pane, and focussing on that pane when it's letter is used.

+-------------------------+
|         1|             2|
|          |              |
|          |              |
|          |              |
|          |              |
|          |              |
|          |              |
|          |              |
|          +--------------+
|          |      3|     4|
|          |       |      |
|          |       |      |
|          |       |      |
|          |       |      |
|          |       |      |
+----------+-------+------+

• movement is deterministic in a very obvious way - there's no doubt where 2 keystrokes will get you
• you can get, for instance, from 2 to 4 also by hitting some sort of "forward pane" shortcut twice, rather than moving to the numerics (same from 7 to 1, just hammering rapidly and repeatedly on the keys you feel comfortable with and ascending / descending through the sequences
• maybe policy to decide which char is attached to which pane is automatic; maybe it's done explicitly, a bit like a "drop bookmark" for the current pane that lets you jump back to it rapidly later