Why are copilot and some other functions not extensions?

[vadim-su]

It appears that the current approach may lead to increased coupling, which could limit the system’s modularity and flexibility. To enhance the architecture, it would be beneficial to develop an API that allows for seamless integration with various suggestion services. This would not only promote a more decoupled design but also enable easier maintenance and scalability. If my understanding hot it works is correct, of course

[SomeoneToIgnore]

Mainly due to the fact that extensions are very immature and their first working prototype appeared much later than any Copilot-related one.

Right now, extension API is very limited and is more about defining language capabilities rather than editor-related capabilities.
IIRC, there's no editor-related APIs at all now, so no plugin can adjust the text or add any graphical adjustment around it.

Until somebody designs those bits, copilot most probably stays inside Zed codebase.

Another reason is the fact that it's faster to evolve the code without worrying about the compatibility — it would be harder to pull off something like #10788 with Copilot being an extension.

[vadim-su]

Yes, I understand. Do you have a good starting point for extending an extension API? I'm open to giving it a try.

[SomeoneToIgnore]

I'm not sure that extracting Copilot now would be beneficial, as there could be more work needed on Supermaven Pro, related Zed infra and whatever else.

I would recommend to look at https://github.com/zed-industries/extensions for extension examples.

There are two main ways extension may get external logic plugged in:

• various *.scm tree-sitter queries for things, predefined in Zed: e.g. brackets.scm will be used by Zed to highlight brackets for this language, runnables.scm would make Zed to render special symbols on the gutter to start tasks, etc.
• zed::Extension trait

  zed/crates/extension_api/src/extension_api.rs

  Line 57 in 66e8739

  pub trait Extension: Send + Sync {

  that may have its Rust code, compiled in wasm, being run.

I would start with the proposal: an issue/discussion with the description of what's the goal, how it changes the API, etc. and maybe a small hacky prototype: there's a number of extensions included into Zed "monorepo", so one can experiment with the API in the same project.
Implementing first editing operations alone might be a tough task to make right, so it would be good to start small.

[versecafe]

@vadim-su On the note of starting small, the ability to create dock icons, panels, and the little pop up windows for icons could be a nice start for getting basic integrations up and running, since right now all of this requires modifying zed directly so a simple extension like the Vercel VS Code extension which just shows the status of your Vercel project requires directly editing crates/zed to register the the panel

[vadim-su]

Thank you for the suggestion! I was thinking of starting with something like this.

[pdenapo]

I agree in that for many use cases the collaborative features or IA of Zed are not needed. For instance, I usually work alone in my code, and I don't have any Open IA/Copilot key. So these features are useless for my use case.
It would be nice to be able to build a light-weighted version of Zed without these features. Less unneeded features
would mean less memory consumption, which is crucial in systems with limited resources.
Also this would reduce the long compilation speed (which is the most serious rust draw-back in my opinion).
A shorter compilation time would mean fastest and easier development.

So definitely, I would love theses features to be moved to extensions or make them optional.