Add a plugin interface to extend the editor

[gracicot]

Check for existing issues

• Completed

Is your feature request related to a problem?

I would like to write a plugin to add CMake support. Currently, as far as I can see, there is no support for writing, browse or install plugins.

Plugins are an essential way to grow the ecosystem of developers and allow anyone to make the editor act as they need in way the Zed developers cannot afford to develop or haven't thought of.

Describe the solution you'd like

I can imagine my plugin be able to do this:

• Add commands to build the project, configure the build system and clear the build directory
• Have the ability to instruct the language server where is the compile_commands.json
• Use triggers to complete actions like updating the build system config when a build system related file is changed
• Show compilation output and configuration output to the user
• Provide a way to display some UI elements like selecting the build profile
• Configure debuggers when Zed supports debugging
• Running a given CMake executable (either from path or a config)

If applicable, add mockups / screenshots to help present your vision of the feature

A good plugin system should be 100% multiplatform and also allow multiple languages. It should also be secure and sandboxed. Rust has an extremely good support for WebAssebly coupled with WASI. A plugin written in wasm would be fast, allow for plugins to be written in Rust and also be multiplatform so only one target is required for a plugin to be used everywhere. Wasm with wasmtime or wasmer has a controllable sandbox and it should be possible to expose an API for Rust, C, and Typescript to allow writing plugin in whatever the plugin developer likes to write.

[mikayla-maki]

Strongly agreed

[johnm]

I guess this counts as piling on but I'll go even a bit further... I'm an old, neck beard Emacs user. And while I don't expect something as wildly open as elisp & emacs, having a plug-in system that makes the guts of zed available for both extension and transformation. This example of plug-in for cmake sounds like a clear example of an extension. An example of what I've called transformation would be to add the capability for me to write a plug-in that would add my own take on Kakoune/Helix/etc. modal editing.

For the curious, I'm way down the rabbit hole of smol programmable split-ergo keyboards. That leads one into the world of layers but also sequences, combos, and all sorts of semi-intelligent features (e.g. a fun one we developed known as Caps Word). Being able to pair programmable keyboard features with programmable editor features is where I want to go. I'm jaded enough with the Emacs ecosystem and yet none of the modern editors really learned the core lesson of its programmability. I really like much of what y'all have done with Zed so far and hoping this becomes a great platform rather than just a cool editor.

[anthonyjclark]

the capability for me to write a plug-in that would add my own take on Kakoune/Helix/etc. modal editing.

layers but also sequences, combos, and all sorts of semi-intelligent features (e.g. a fun one we developed known as Caps Word)

Being able to pair programmable keyboard features with programmable editor features is where I want to go.

I completely agree with these statements. I created my own modal setup for VS Code using https://github.com/DCsunset/vscode-modal-editor, and I'd love to do the same for Zed. I keep hoping for one of Zed, Lapce, or Fleet to add this functionality.

[mediabeastnz]

🤞

[jrmoynihan]

The easiest way to cut into VSCode's moat is to create an easy way to port those VSCode extensions into Zed. An adaptor interface of some kind would go a long way. A major advantage of a robust extension ecosystem is that it teaches the community what features users want, but don't have yet. This would add additional value as a feedback loop for the Zed team.

[so1ve]

Maybe zed can load wasm plugins? like what dprint does?

[fkhoda]

Extism might be a good fit to support WASM-based plugins as well. It also includes support for multiple languages.

[avrame]

This is really the only issue holding me back from using Zed full time. With a plugin system, many of the other issues would be solved as the community could solve it by making it a plugin. I also think WASM is a good way to go so that the plugins can be written in pretty much any language.

[wzxu]

I think this is especially crucial to Zed because compared to VS Code, 1. Zed is closed source, and 2. not backed by a huge corporation. It's just impossible for Zed's developers alone to keep up the pace. Sublime Text's development is also slow and even went dead for a while, but with plugins it still remains pretty relevant.

[ayame113]

I think it might be possible to implement a JavaScript-based plugin system using Deno.

• Roll your own JavaScript runtime - Deno
• Roll your own JavaScript runtime, pt. 2 - Deno

[maddanio]

to also put a lower hanging froot into the room: a huge number of issues here would be solved by simply allowing new languages. that would not really need a plugin, just a way to detect them and specify an lsp

[haikyuu]

I think it might be possible to implement a JavaScript-based plugin system using Deno.

This is a great attempt at that for neovim https://github.com/vim-denops/denops.vim
I find this a great fit for Zed

[ThatXliner]

Personally, I think a WASM system like https://github.com/lapce/lapce is a good idea

[sachaw]

Worth considering:
https://extism.org/

[berkus]

Will Zed be the first to support multiple plugin languages? Exciting!

[sirenkovladd]

Will Zed be the first to support multiple plugin languages? Exciting!

Actually no, because above mentioned lapce and also vscode support wasm
therefore, zed will not be the first to support multiple plugin languages

[simonzkl]

When designing the plugin system it would be nice to support some sort of early initialization phase that plugins can hook into to set process environmental variables that other plugins (e.g. language servers) might depend on. This would be useful for #4977 (direnv support).

See #4977 (comment) for more context.

[noozo]

My (maybe unpopular) two cents: Multiple language plugins might become a nightmare to maintain in the long run. Just make the system in Rust (which is a nice enough language) and be done with it :)

[so1ve]

Just use wasm :)

[TheBlckbird]

My (maybe unpopular) two cents: Multiple language plugins might become a nightmare to maintain in the long run. Just make the system in Rust (which is a nice enough language) and be done with it :)

WASM.

[konsumer]

Yep, I agree with others. WASM-based plugin system would be sick. You can target WASM in just about any language (including rust) and the plugins don't need to be recompiled per-machine/os, or need a complex/large interpreter, and are fairly efficient. WASM also has profiling and sandboxing that make it very good for any plugin-system. It doesn't even need to be full WASI host or anything super-complicated, just like a central event-responder that has access to current buffer/selection and can trigger other zed-commands. Figma used this to allow users to make plugins in any language (most use rust and C++) and use them on the desktop (any supported platform)/web app, with no recompile. You can compile rust, c, micropython, nelua, assemblyscript (typescript) and many more languages to wasm once, and they just drop-in, with no modification. I think a key thing is ignoring the W in WASM, and just thinking of it as a performant cross-platform, cross-language way to record CPU operations. Like it's great outside of browsers, too.

There is already this for theme/languages/grammars, but I think personally the plugins I would use most often would be "when you hit this key, call this command that does something with source in current buffer, on current line." A combination of these would be very cool (wasm for actual behavior, config for theme/grammar.)

I'd be happy to help, if this all seems like a good idea.

Not having plugins is the only thing that makes me not use Zed full-time (I really like emmet for JSX, for example.) I normally use sublime.

Sidenote: Looks like emett can be done in a language-server (emmet-language-server or emmet-ls) too, so at least for that, it may just be a config-thing. Writing a custom language-server in wasm would also be very cool. Here is a bit about an in-browser wasm-based LSP, and although I dunno if I agree plugins should have filesystem-access (it may be the only way to index all things, though, I dunno) I think the general idea is a good one.

[ThatXliner]

I think, like Xi, plugins should have access to the document in the form of a CRDT cursor.

[xpe]

I think, like Xi, plugins should have access to the document in the form of a CRDT cursor.

I haven't read the Zed source code, but based on reading some blog posts, I'd expect that Zed uses something like a CRDT over a rope.

Somewhat relatedly: as I understand it, the developers want more and more customizability in the form of (loosely speaking) scriptability. From the Zed blog dated 2024-February-12:

You know, I remember using Emacs and thinking it was so cool that you could extend it, but you're sort of operating at the character level. So that was part of the original vision too and now Max has achieved that with Tree-sitter. You know, basically scriptability. We're not scriptable yet, but we'll get there. But when we are, we'll have access to a richer representation of the text than just looping over characters or whatever I was doing in Emacs. I mean, they probably have that now as well, right? Because Max wrote tree-sitter.

[brandondrew]

Since extensions already exist in Zed, is there any documentation for how we can create our own?

I use Zed by choice (most of the time) and HAML for legacy reasons, but it's driving me crazy that I can't do basic things like toggle multiline comments in HAML. I started down the rabbit hole of creating my own HAML plugin, but I couldn't find any documentation.

I'm not looking forward to going back to VS Code for all my HAML files. 🙁

[colinta]

Many people mentioning VS Code, so I'll be the one to say please do not model yourself off of VSCode's plugins. It's bizarre to me that writing a plugin should be this level of tedious. Sublime Text got it right: open a file that is in the right folder, save it – and the editor (re)loads your plugin and you're done, back to work.

[maxdeviant]

Since extensions already exist in Zed, is there any documentation for how we can create our own?

I use Zed by choice (most of the time) and HAML for legacy reasons, but it's driving me crazy that I can't do basic things like toggle multiline comments in HAML. I started down the rabbit hole of creating my own HAML plugin, but I couldn't find any documentation.

I'm not looking forward to going back to VS Code for all my HAML files. 🙁

@brandondrew We're still a little light on docs for extensions, but we do have a quick guide for getting started with making an extension.

Aside from that, we have a lot of examples of extensions in the extensions directory in the Zed repo. These are all extensions that we extracted out of the Zed binary.

[maddanio]

Will there also be custom commands and build system integration? And integration with the editor aka inline type display, git status/blane etc?

[brandondrew]

Will there also be custom commands and build system integration? And integration with the editor aka inline type display, git status/blane etc?

@maddanio git blame was added in the last few days.

[maddanio]

My question was about the extension api, so far i could only see lsp integration, no build Systemintegration, commands, editor interaction, text manipulation etc

[mocenigo]

My (maybe unpopular) two cents: Multiple language plugins might become a nightmare to maintain in the long run. Just make the system in Rust (which is a nice enough language) and be done with it :)

Not necessarily. If the plugins have a well defined interface to the application, then the interface files for various languages are going to be stable. But I am also sure that we need a more "official" way, such as a scripting language.

I am a Lisp person, with a sweet spot for Scheme, but I understand that this can scare people. SublimeText uses python and it is a very powerful language for prototyping software quickly. So RustPython seems a good option, if the WASM compiled software can also be run embedded in an application with Wasmtime: on fact, one can always use the interpreter, maybe even access a REPL, and once ready, compile. If Extism can help here, making packaging easier, then it would be welcome.

Another advantage is that python plugins/extensions for SublimeText could become somewhat portable. In fact, I reckon that to eschew from using node.js or Deno may be wise, otherwise there would be no incentive to use anything but Atom/VSCode extensions, with the performance and threading problems they carry with them. Also, this would make Zed heavier than VSCode, which would contradict one of the motivations of the Zed projects in the first place...

[maxbrunsfeld]

Zed now has a plugin interface. So far, we've focused on languages, themes, and language server adapters. But the path is paved for building other kinds of plugin APIs.

I'm going to close this out, and I encourage folks to open further issues for specific plugin capabilities that are important.

[maxbrunsfeld]

Our docs for creating extensions are currently here: https://github.com/zed-industries/extensions/blob/main/AUTHORING_EXTENSIONS.md.