Syntax highlight on nested sub projects from the file browser - command clicking completely not functional

[reduxdj]

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

Syntax highlight on nested sub projects from the file browser, does not syntax highlight (in Rust), other non-nested projects, syntax highlighting still works...

Expected behavior

Expect syntax highlighting, command clicking and all things to work no matter if its nested n levels deep.

Environment

echo $(zed --version) "\n"macOS $(sw_vers -productVersion) "\n"architecture $(uname -m)

Zed 0.65.2 – /Applications/Zed.app macOS 12.5.1 architecture arm6

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue

No response

[reduxdj]

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

[maxbrunsfeld]

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.

[reduxdj]

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.

[eth0net]

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 🤣

[eth0net]

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 🥳

[eth0net]

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 🤔

[eth0net]

Looks like this issue has already been fixed to me!

[eth0net]

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.

[eth0net]

Yep, this fails

And this works