Path-dependent directional navigation?

[yuhan0]

Yabai's algorithm to determine the target window in a given direction is not very intuitive, it doesn't appear to be based on geometry or tree structure. As an example, moving right from A puts me on C.

 ┌──────┬──────┐
 │      │  B   │
 │      ├──────┤
 │      │  C   │
 │   A  ├──────┤
 │      │      │
 │      │  D   │
 │      │      │
 └──────┴──────┘

But in this slightly modified scenario, it puts me on D.

┌──────┬──────┐
│      │  B   │
│      ├──────┤
│      │  C   │
│   A  ├───┬──┤
│      │   │  │
│      │ D │ E│
│      │   │  │
└──────┴───┴──┘

Perhaps it is window ID based? In any case it is difficult to predict, and the best course seems to be resorting to mouse-based actions in these "ambiguous" situations.

---

By analogy to most people's experience with text editors, if you have lines of different length, with the cursor at the end of the first line:

abcde|
fgh
ijklmnop

and move down two lines (↓↓), the expected behavior is to land at the letter m (position 5).

abcde
fgh
ijklm|nop

A naive implementation would "clip" the cursor's horizontal position upon encountering the shorter fgh line, ending up on k.

This is how Yabai currently behaves - if I have the following layout with C selected, navigating ↑↓ should return me to C, but instead sometimes B is selected.

 ┌───────┐
 │   A   │
 ├───┬───┤
 │ B │ C │
 └───┴───┘

The same goes for swapping and warping windows - if If want to place A next to C, the natural action may be to move up and warp down, but this results in A/B C and not B A/C. "Downwards" of A is always B, regardless of the path history.

In the text editor analogy, there is an implicit "horizontal position" state that is persisted across vertical movements, and any horizontal movements would override it (↑←→↓ in the above example should place me on k). For many people I believe this is quite a subconscious ingrained understanding of user interfaces, and having it violated is an unpleasant flow-breaking experience (especially with no "undo" action available)

In our 2D scenario, I suggest that Yabai should implement an X and Y memory state according to the centroid of the selected window. Horizontal actions would update the X but persist the Y state, and vice versa for vertical actions. Attempting to navigate against a screen "border" would establish the state in that axis instead of being a complete no-op.

Possible variations

• Use the upper left corner as a datum instead of the centroid? As long as it is consistent and allows the user to build a mental model for the "virtual caret position"
• Have the X/Y datum flush to the edge of the window in the direction of movement? A↓B→E whereas C↑B→D in the following scenario

 ┌─────┬─────┐
 │  A  │     │
 ├─────┤  D  │
 │     │     │
 │  B  ├─────┤
 │     │     │
 ├─────┤  E  │
 │  C  │     │
 └─────┴─────┘