Switching projects with common folders doesn't work

[eth0net]

Summary

Switching between projects that share folders doesn't always work.

Steps to trigger the problem:

1. Open a few dirs in Zed zed ./a ./b ./c to create a project
2. Close the project window, or Zed completely
3. Open one of those dirs in Zed zed ./c to create a new project
4. Switch to the multi dir project in the project switcher

Actual Behavior:

• Check the project switcher and the single dir project is gone
• Check the sidebar and the remaining dirs have been added from the multi dir project, but appended after the single dir, changing the order of the project

Expected Behavior:

• Single dir project should still exist in the switcher
• Multi dir project should be opened in the original saved order of the dirs

Zed Version and System Specs

Zed: v0.176.0 (Zed Preview) OS: macOS 15.4.0 Memory: 36 GiB Architecture: aarch64

[eth0net]

It seems you can also do it similarly the other way:

Steps to trigger the problem:

1. Open a single dir in Zed zed ./c
2. Close the project window, or Zed completely
3. Open multiple dirs including that one zed ./a ./b ./c
4. Switch to the single dir project in the project switcher

Actual Behavior:

• The project hasn't switched, you are still in the multi dir project
• The single dir project is still in the switcher list

Expected Behaviour:

• The project switches to the single dir project
• The multi dir project is in the switcher list now

[eth0net]

FYI this used to work, only noticed it today but I'm not sure exactly when it last worked for me, though it has been at most a month I think.

[probably-neb]

Yeah that's annoying. Hopefully we'll be able to catch where this bug snuck in with a git bisect if it used to work. Thanks for reporting!

[eth0net]

Just noticed this also happens from a new Zed window if a clashing project is open in another window, even if the clashing project has additional directories.

Steps to trigger the problem:

1. Open a few dirs in Zed zed ./a ./b to create a project
2. Close the project window, or Zed completely
3. Open one of those dirs and a new one in Zed zed ./b ./c to create a new project
4. Open the original list in Zed zed ./a ./b

Actual Behavior:

• a is now visible in the window with b and c
• Only one window is open

Expected Behavior:

• Original b and c window remains
• New a and b window is opened

Zed Version and System Specs

Zed: v0.182.8 (Zed Preview) OS: macOS 15.5.0 Memory: 36 GiB Architecture: aarch64

[eth0net]

~~Think this might be related https://github.com/zed-industries/zed/pull/24560~~

Ignore me, a build of the commit before on main didn't work either.

[eth0net]

Okay doing a manual binary search checking out commits in Jan/Feb I found it's this commit, which doesn't look like a fun one to unwind 😔 6fca1d2b0ba93cdbc3255657a990828a0f22b199

The one before it works as expected.

[eth0net]

Pretty sure it comes down to this check (running it through with the new debugger)!

https://github.com/eth0net/zed/blob/fcf50420071e213896d8df6e4ce3475284e2ecb1/crates/workspace/src/workspace.rs#L6788

As I understand it, any open workspace with 1 or more matching paths becomes a candidate instead of just opening the target as expected. I think to fix this we need it to only consider 100% matching windows rather than windows with at least 1 path matching.

[eth0net]

Just checked the latest release of Zed and this issue is still present 😔

I'd appreciate some help figuring this one out as I have been having to work around it by first opening a new Zed window, closing my old window with the first project, and then opening the second project in the new window.