Change pane navigation to work like tmux

[mtn]

Hey! This PR contains rough experimental code for changing the pane navigation behavior in Zed. I wanted pane navigation to behave like tmux:

https://github.com/user-attachments/assets/e2904d9a-8473-42dc-a03f-3663cbde3fca

1. If I have the layout

A | B
A | -
A | C

and go from C -> A and then go right again, I should end up back in C, not in B.

2. If I'm in the rightmost pane / dock and navigate right, I want to end up in the left-most, etc.

3. Relatedly, there's some behavior about jumping to the last active panel from a dock that feels weird to me (https://github.com/zed-industries/zed/discussions/31396)

The code in this PR changes these three things:

https://github.com/user-attachments/assets/5eb7eaea-b683-48b4-8762-772ed01c5889

There's no tests yet and a bunch of debug logs / UI artifacts that still in. Before I go and clean that up, could I get a high-level review on the behavior change?

Related issues / discussion:

• https://github.com/zed-industries/zed/discussions/31396
• https://github.com/zed-industries/zed/issues/20738
• https://github.com/zed-industries/zed/discussions/24109

[cla-bot[bot]]

We require contributors to sign our Contributor License Agreement, and we don't have @mtn on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[mtn]

@cla-bot check

[cla-bot[bot]]

The cla-bot has been summoned, and re-checked this pull request!

[probably-neb]

Hey, I'm not sure about this, especially point #2 as I don't think this is very intuitive. I think we want to aim for the most intuitive navigation we can, rather than "what x does". I'm also worried about the maintenance burden on our end with this, as most of us aren't heavy tmux users, it will be hard for us to tell bug from feature.

Therefore, even though I personally think this is cool as a former heavy user of tmux, I'm going to close this for now. I am open to being convinced otherwise, so feel free to let me know your thoughts. I also suggest opening a discussion for this so other people can chime in for or against this change. And finally, as always, the fork button is there for cases just like this!

[mtn]

Hm, ok. I agree that the justification for adding circular navigation isn't particularly strong. If you don't want to merge it, I have no objection, though I did open a discussion thread or issue for all three features and got what I interpreted to be a tentative green-light before implementing this: https://github.com/zed-industries/zed/discussions/24109.

What about 1 and 3? For what it's worth, nvim behaves the same way as zed currently does on 1, though on the issue I opened (https://github.com/zed-industries/zed/issues/20738) I also got what I understood to be acknowledgement the current issue is a bug. 3 doesn't have an equivalent and the behavior just feels wrong. For example, set up the following layout:

A | B | C

Where A is the left dock and B and C are editor panes. If you click on pane C, then click on dock A, then trigger a move right, you'll jump to pane C.

[probably-neb]

Yep, agreed the issues you described are bugs and I would be happy to have a fix for them no matter what! However, I also think that having those bugs fixed and having our pane navigation work like tmux are independent of each other.

cc: @SomeoneToIgnore on this, I was unaware of his prior comment on this idea. While I personally am not sure this is the right direction for Zed, like I said before I am willing to be convinced otherwise!

I'll re-open tentatively for now, sorry to close so aggressively

[SomeoneToIgnore]

I am not using these features so advanced, so cannot have a good preference.

1. Overall, the circular approach looks interesting, but how this supposed to work with other actions that operate SplitDirection?

For example, currently, workspace::ActivatePaneRight, workspace::SwapPaneRight and workspace::MoveItemToPaneInDirection actions reason similarly about the "next pane to the right": if there's none, they either abort or create the new split pane first and continue with the operation; nothing ever wraps over the edge.

Now though, if we allow wrapping over the edge for navigation, would there be more uncertainty like "I want to MoveItemToPaneInDirection to the right so that there's new a new split" vs "I want to do the same action to the right so that it moves circularly, to the first panel". How are we supposed to adhere to all?

2. The PR considers a single pane group, it seems, the central one. Zed now can split the terminal pane, and there's already a navigation invariant that unites both the central and terminal worlds: https://github.com/zed-industries/zed/pull/21313

Also, while not implemented properly, terminal elements may exist in both panes (otherwise, terminal pane does not allow non-terminal items) and moved between panes.

---

I do not think it's reasonable to ask for all this implemented at once, but reasonable to ask to consider the entire navigation and movement picture when discussing this in the beginning.

Not sure what this PR proposes on the topic, let's draw a bit more transition diagrams?

[mtn]

Thanks, I'll elaborate on what would feel like consistent behavior for each of them and then we can decide which if any make sense to do. Might be a few more days.

[SomeoneToIgnore]

Given the conflicts and 2 months of inactivity, I'll close this as stale to fee the PR queue.

Overall, seems like a good change to have, but the model is a bit more sophisticated than just editor splits as we've now learned — outlining that would be a great first step in the new impl.