Would it be possible for End Users to add their own support for new languages?

[peter-wasilko]

It would be nice for the community to be able to provide support for languages that aren't baked into Zed.

Ideally, this could take the form of a DSL based on the Parsing Expression Grammar formalism and an optional preference setting to point Zed to a corresponding Language Server Protocol based Language Server if one exists.

Alternatively, could Zed:

• Leverage the VSCode Ecosystem of language plugins.
• Delegate the task to a command line tool like pygmentize.
• Adopt the LaTeX Listings package's rather intirguing approach to defining language drivers? See sections 3.2 and 4.17 of the package documentation.

[clo4]

I don't work for Zed, but I think I could answer this.

• Making it easy to support other languages is a core goal of the editor but isn't priority right now
  • Currently it's more important that a smaller subset of things work perfectly, than have a large number of features that don't
• Zed syntax highlighting is built on tree-sitter, so adding support for other languages will definitely be possible in the future.
  • This gives it a better understanding of the actual code structure than TextMate grammars ever could, and means you can get some language features without even needing a language server
  • In a way, it already does use a DSL for LR(1) grammars, just with an additional layer of abstraction in that they're compiled to C by another tool the Zed team wrote back before they were even Zed. That's pretty fun.
• "BYO language server" is WIP but there's no timeline for releasing this (https://github.com/zed-industries/community/issues/94#issuecomment-1160646440)
• Once the extension API is implemented, that door can't be closed. Needs to be designed with performance in mind from the start to not end up with Atom again. This will likely use WebAssembly because
  • You can build extensions in any compiled language that supports wasm as a target
  • Zed can continue to hit its aggressive performance target
  • Zed can run extensions on another thread
  • It's JIT-able and there are already multiple very lightweight wasm runtimes for Rust.
• Supporting VSCode extensions is a huge undertaking. IMO not a good choice.
  • Baking in support for the entire extension host API not only requires bundling a JS runtime (node), but also supporting a lot of likely incompatible features. So I think it's probably out of the question
  • Onivim 2 tried this and it ended up being a massive pain to implement and constant source of bugs

[Yevgnen]

I think the first step would be the ability to use custom language server. I really like jedi-language-server much more than pyright in Python.

[JosephTLyons]

We are working on support to allow users to choose their own language servers. Its still early on, but I'm excited for Pylyzer:

• https://github.com/mtshiba/pylyzer

[ijsnow]

I think the easiest, bare-minimum improvement would be to add a tree-sitter grammar to support things like graphql

[xpe]

Lots has changed with Zed since October 2023 -- Zed is open source and allows extensions. What document(s) are good starting points for adding (1) a new grammar; (2) a new extension with a grammar; (3) a new extension with a custom LSP? (Sorry if this three-way split is inaccurate; it is based loosely on how VS Code does it; please correct me.)

[SomeoneToIgnore]

The best place is https://github.com/zed-industries/extensions that contains a small document on how to start with a new extension (and which could be improved, if unclear) and has all current extensions inside, as examples.