Status of third-party language plugin system?

[tzakharko]

Many months ago the Zed team mentioned that they are working on a plugin system which would allow integration of other languages and tools than those supported by the core editor. Frankly, for many of us this ability is paramount (I can't even use Zed for an occasional TypeScript project because I usually work with Deno and Zed locks you into Node). There are currently 79 open issues regarding support of various languages and syntaxes, for many of which both the treesitter grammar and a language server are readily available, but it doesn't look like any visible work was done to allow integration. Same goes for a build system, which is a highly requested feature.

Now I see that work is underway on a Zed2, and I was surprised that there is no mention of language plugins or build system. Are these thing still planned? It would be really great to get a statement from the authors. I really like the look and feel of the editor, and I think that it would be a great fit for my group, but without custom language server integration it sadly cannot be used for our work.

[JosephTLyons]

Hey @tzakharko, it is true that on two or three separate occassions, we began work on building a plugin system. In each of those, we learned something, but ultimately ended up scrapping the work, because we weren't quite sure if we wanted to settle on using rust + wasm and because of things being trickier than we expected. The work being postponed was mainly meant to give us more time to think about what language / tools we want to initially support as our official plugin language. Since then, we've talked about using JavaScript / Node and Python. We still fully intend to make Zed customizable, by putting out an extensions system, but we are currently focused on Zed2 at the moment. I do want to state that Zed2 is not a bump in the version number of Zed, it is not meant to be Zed 2.0.0, it is merely an alias we've given Zed to help differentiate between whether we are referring to Zed that uses our original GPUI framework, or the second iteration of GPUI. The confusion here is definitely our fault, as we never really explained it in blog posts. This is an entire application rewrite, but it is extremely necessary, as it will enable us to ship UI changes much faster going forward. Previously, UI dev was slow, complex, and a bit all over this place. Zed2 enables our designers to write Rust code in a way that feels very familiar to them and lets them change and ship things super fast. So while this transitional period feels to be dragging on, we will gain this time back in the end, with the ability to quickly improve things going forward.

After we finish the port, we will focus on open sourcing Zed, as this is an even more general thing that will unblock the community. People can come in and help fix bugs / add features (ex: help us build the plugin system!). Extensibility will likely be one of the very first things we revisit after the port and open source is done.

Here's a tracking issue for the open source stuff:

• https://github.com/zed-industries/community/issues/2197

I'll post another update screenshot in there today - we are getting closer and closer to having a fully functional application.

[Decedis]

Now that the project has been open-sourced, are there any new plans for the plugin system?

[tzakharko]

Dear @JosephTLyons, thank you for your reply and clarification. I certainly understand your motivation behind the UI framework rewrite and being no stranger to editor design myself I know how complex these things can be.

Regarding the plugin system — full-fledged extensibility (like Sublime does it for example) is something that's very easy to get lost in (both as a developer and as editor identity), so I think your careful approach makes perfect sense. I also really like your focus on core editor functionality — too many of really extensible editors tend to become a mess over time, with low-quality plugins polluting the search space. Frankly, I'd rather have a solid set of editing tools than a fully extensible editor.

At the same time, I also think that a case can be made for starting with a much simpler extension system which initially only implements LSP server discovery, additional TreeSitter grammar integration, as well as a simple build system that invokes an external tool. This would already cover a large amount of useful extensibility while giving ample opportunity to experiment with plugin design spaces (bundles/plugins aka. TextMate or rather minimal autonomous "features" for example). Of course, that's just my 5 cents, and I'm certain that you have a much more detailed vision of what can work and what does not.

If you ever decide to have an open discussion on these matters, I'd be happy to contribute.

[JosephTLyons]

I think we are planning to do it in stages, like you suggested.

First stage: Allow for custom tree sitter grammars
Second stage: Allow for custom language servers
Third stage: Allow for plugins to modify UI (adds panes, etc.)
...

[stjepangolemac]

I also want to add something to the plugin system discussion and that is considering an approach that is perhaps a bit uncommon.

• Every plugin is started up as a separate (child?) process
• Communication is done through standard pipes
• Messaging format could be something simple like a stream of JSON messages
• Zed starts up all plugins on startup and communicates the current state
• A thread continuously reads all messages and lets the rest of the system know
• This is simple to architect for an MVP
• This could also be wildly extensible (supporting a more efficient binary communication format, multiplexing streams so that plugins can send messages while streaming a video into the Zed UI)
• This is probably very easy to scale as plugin communication can be divided over N threads

Original: https://github.com/zed-industries/community/discussions/2321#discussioncomment-7827914