lsp: Check for existing snapshots before sending off a didOpen notification

[osiewicz]

Closes #ISSUE

Release Notes:

• Fixed Zed sending out didOpen notification to a language server when opening documents.

[osiewicz]

/cherry-pick v0.175.x

[bajrangCoder]

after this pr uno-language server starts to fails, as this name is undefined.
Previously it used to work.

[osiewicz]

@bajrangCoder Thanks for reaching out and diagnosing the issue; this is probably unrelated to this PR as this one doesn't mess with server initialization anyhow.
If anything, #25337 would've "broke" it as a follow up to #24038
However, I don't think the fault is on our side, as the server you've linked:

• Does not check for client capabilities for handling workspace folders in the first place (it only does so after accessing workspace folders).
• Does not support dynamic registration of language servers (not their fault per se, but it renders them fundamentally incompatible with Zed with project: Fine-grained language server management #24038)
  I feel strongly that this is an issue that should be resolved upstream by fixing two of the points stated above.

Besides, they're also accessing.. name of the workspace folder? Not even the URI, which is what we fill out (we leave the name empty). This means that you could probably unconditionally run resolveDir function with either the name from the first workspace or some default (like "") if none is found. This feels to me like a relatively straightforward solution if you're willing to run your own fork.

[bajrangCoder]

Thanks for your help!

Btw, I apologize for mistakenly disturbing the wrong PR.

I also came across several strange issues in the server and also some missing stuffs, which is why I started implementing my own from scratch. However, due to my exams, the development is currently on hold, but I plan to resume it once they are over.

Actually, a user reported an issue on zed-unocss, mentioning that the extension fails to start the LSP server on Zed 0.175.3 Preview. That’s why I thought something might have changed in Zed.

[osiewicz]

Don't worry, it's okay to ping as long as it's at least somewhat related. :) And yeah, Zed changes broke it, but I'd say that the changes we made are reasonable and the language server for unocss is the odd one out.

[tuzemec]

I've created a PR to the unocss-language-server that I hope resolves the first issue.

But I'm not sure how to approach the dynamic registration part. Is there some documentation that I can check? I can't quite figure what's happening in #24038 (maybe it's about time to learn some rust...).

[osiewicz]

Oh, sorry, my wording was a bit imprecise:

Does not support dynamic registration of language servers (not their fault per se, but it renders them fundamentally incompatible with Zed with #24038)
I feel strongly that this is an issue that should be resolved upstream by fixing two of the points stated above.

It should've said dynamic registration of workspace folders. Previously we've always had only one workspace folder per workspace, which we provided on server initialization and we never updated the list (there can be multiple workspace folders per project).
#24038 changed that. Language server protocol allows us to report workspace folders on the fly via DidChangeWorkspaceFolders notification - the server has to support it though, and unocss does not do that.

Honestly your PR looks good to me. It'll make unocss work just as well as prior to #24038. #24038 is really about improving language server support in large projects, e.g. monorepos.