[diodak]

Hey, my name is Piotr and I work on language servers at Zed.

Right now you can run multiple language servers in a single project. Admittedly you cannot have multiple instances of a single language server in a single worktree (e.g. two rust-analyzers) - I am working on that right now, as this is a common pain point for users with monorepos.

I would love to hear more about the problems you are having with running language servers in your projects. Is there any chance for us to speak on our community Discord or via onboarding call (which you can book via https://dub.sh/zed-c-onboarding)?

[rbetts]

I've been using Zed (with python) for the last few weeks (coming from vscode and nevim). There's a lot I like about Zed. My favorites include the speed and navigation via the symbol outline (and vim mode). I'd have a hard time going back to vscode. The LSP configuration, though, is not one of its best parts, for me. I ended up copy/pasting a few different ruff + pyright configs until one mostly worked and puzzled through how to map the settings from linked pyright docs into Zed yaml. Some better documentation for the configuration stanzas and how they map across the different tool's settings would be really helpful.

I still, for example, can't get Zed / LSP to provide auto-fix suggestions for missing imports. (Which seems like a common stumbling block: https://github.com/zed-industries/zed/discussions/13522, https://github.com/zed-extensions/java/issues/20, https://github.com/zed-industries/zed/discussions/13281)

I'm sure given the breadth of LSPs, that they all have their own config, and use different project config files, makes it hard to document clearly. But it's an area that I hope bubbles up the roadmap in due course.

[celdon25]

I'm curious if you've given thought to improving json-schema support. Zed just packages VSCode's implementation (https://github.com/zed-industries/json-language-server ), which is generally decent, but hasn't been able to keep up with the spec, and I doubt they ever will at this point (Example: https://github.com/microsoft/vscode/issues/165219).

The newer specs for json-schema (not supported by VSCode) allow for a wider range of data requirements to be supported by a schema without that schema resorting to costly workarounds. VSCode's level of support for this is decent, but is still a pain point as it creates a sort of artificial restriction on the layout of your data that you're able to have without unexpected development costs. This of course can lead to missed estimates and reduced morale.

I understand that very few developers are directly producing and maintaining schemas. Those schemas do have an impact on most developers though. I think this is a problem that is being sadly overlooked, and I hope you can consider changing the status quo.

Love the company name btw, sounds similar to my own Nuzz Industries (not a real company, just a tag I've slapped onto some projects occasionally as a homage to Page Industries from Deus Ex).

[lionkor]

Hi, thank you. I specifically meant running multiple LSPs in the same file at the same time, akin to vscode.