Plugin System about athens

[alaq]

Ideally extensions should be compatible with the desktop version as well as the web based version so maybe web workers are more appropriate? I believe you can also use web workers in Electron.

I also like borrowing VS Code's vision. It's encouraging that other applications are able to share extensions with VS Code, like onivim 2.

In terms of distribution, I like how Ulauncher is doing it. You can simply give it a git repository (so GitHub, GitLab, or self hosted git all work well), which doesn't prevent us from having a plugin registry. The plugin registry is another good project for learners (cc @tangjeff0 @itsrainingmani).

[jeroenvandijk]

TODO

• Collect keycodes
• Demonstrate activation of keycodes with devcards (write on-keypress event listeners)
• Use event listeners in components

[tangjeff0]

Will re-open when after v1 is complete

[thesophiaxu]

Related: #291
It contains a sample plugin API of using custom event hooks w/ custom components and slash commands.
Closing that one (^) because we already have this.

[thesophiaxu]

Agree a lot with @tangjeff0 's vision of building an extension architecture like VS Code. Here's its extension architecture and philosophy for reference: https://vscode-docs.readthedocs.io/en/stable/extensions/our-approach/ It basically has an extension host that is in a seperate worker thread which communicates with the parent thread primarily via events. Because VS Code is a desktop app, its plugin host is in a Node.js thread; but Athens could decide whether to use web workers (directly inside browsers) or build it into our Electron app.

What are your thoughts? @tangjeff0 @jeroenvandijk @itsrainingmani

[thesophiaxu]

@alaq Great input! Yes, web workers work in Electron as well. I am also thinking about talking to the devs of Obsidian to see how we can build a partially common API so that some plugins could be shared between Athens and Obsidian.

In terms of distribution, I think it's a bit too early to think about a full extension registry, but I do like your idea of using git repositories for extensions. In the relatively short term, we can have a temporary manual "featured" extension registry, while enabling custom extension imports via git repositories or zip files.