by the way opening directly from surrounding directory works, for instance, navigating directly to sub directory and issuing a zed . syntax highlighting returns ...

Thanks for the report. Can you explain this a bit further with a specific example? I don't understand how how the project file browser relates to syntax highlighting, and what exactly you're seeing.

OK, i can't really show you my current work project, but for some reason I have a project path that looks like the following, when i hover over a directory from opening the project directory syntax highlighting doesn't work.

project/rust/some_app/main.rs
project/rust/some_app/cargo.toml

and if the the some_app folder directly, then the syntax highlighting works. It seems like subfolders more than 1 level deep syntax highlighting fails for these folders. I had another engineer on our team notice the same thing and the work around also works for them as well.

I believe I'm running into the same problem here, with language servers only working if a Cargo.toml or go.mod etc is found in the root of the project.

Rust and Go aren't working when I open the root of the repo, but Rust is working as normal if I open the aoc2201 directory itself.

Not sure on best practices for handling multiple language servers simultaneously, but this works in VS Code and IntelliJ, and I 100% prefer Zed 🤣

I found a cargo workspace in the project root solved my issue, so posting it in case it helps others 😄

Just create a workspace Cargo.toml file with all your sub projects included 🥳

Noticed this issue has the Rust label, though it applies to Go as well, and may not be limited to those two.

The issue is that Zed isn't loading LSPs without seeing appropriate files (i.e. Cargo.toml) in the root of a project folder and ignores such files found in subdirectories.

To address this, Zed could recursively check each directory to see if it's a LSP-worthy project, or require project roots to be workspaces to handle nested projects. There might be a way to create virtual cargo/go workspaces without the user defining them, but that might be over-complicating things.

Going to test to see if this is still present before trying to think on this more 🤔

Looks like this issue has already been fixed to me!

Oh I've run into the issue again, but with the Zed extensions repo! Might be that one level of nesting works but not more. Going to open a PR to add a workspace file there to account for it.

Yep, this fails

And this works

Hi there! 👋
We're working to clean up our issue tracker by closing older issues that might not be relevant anymore. Are you able to reproduce this issue in the latest version of Zed? If so, please let us know by commenting on this issue and we will keep it open; otherwise, we'll close it in 7 days. Feel free to open a new issue if you're seeing this message after the issue has been closed.
Thanks for your help!

Thanks for confirming it @eth0net ! I'll take a look in a near-ish term at improving this part of our LSP handling.