RFC 40 - Dendron Plugins

[SeriousBug]

This is the discussion for Dendron Plugins RFC.

[kevinslin]

Nice writeup! Initial thoughts:

• +1 on the yeoman
• +1 on being able to mix and match different plugin types

In regards to the registry, can we just use github as the registry?

We might want to take some points from the obsidian plugin community:

• GitHub - obsidianmd/obsidian-api
• GitHub - obsidianmd/obsidian-sample-plugin

The way they do plugin submissions is by adding on to a json file:

• How to add your plugin to the community plugin list - Obsidian Publish

[SeriousBug]

That's a good idea, I'll update the RFC.

[ghost]

I would add Themes as a Possible further type that should be included in the Plugins.

[ScriptAutomate]

I'm wondering if others have seen what MyST is doing:

• Homepage for Docs
• Syntax Docs
• JavaScript Parser of MyST
• MyST-Markdown VS Code Extension

They have been working on extending CommonMark to merge with a lot of the strengths from reStructuredText, and have been working on other tools like a VS Code extension for parsing, and an npm package for parsing the Markdown to HTML (which then is augmented by whatever Sphinx themes they use in publishing), etc.

This has allowed them to do things like implement "directives" in Markdown as a standard format for special properties to things like images, admonitions, and for entry points for plugins to integrate well directly within the Markdown. Sphinx had to go this route, in the Python community, to help make documentation easier, flexible, and extensible in the Sphinx community.

I can see this being powerful with plugins in Dendron, giving things like preview and publishing extended rendering powers.

Now, Sphinx focuses on the publishing results: generated sites, LaTeX / PDFs, man pages, etc. So they aren't focused on the UX/DX experience in making docs, which is Dendron's major strength. BUT, it's really interesting seeing their flavor of extending Markdown so that plugins have a common entry point through directives, which then get parsed to enhance the generated HTML, etc.

With that being said:

• Next.js custom themes is a separate RFC/Discussion, but I feel like plugins can serve a dual purpose: extending the powers in the editor, but also in the preview/published results. Would this RFC on
• I saw mention of CLI, so does this mean that plugins can both extend the power of dendron-cli and extend the power of the VS Code extension, or be targeted to one or the other?
• Have we thought of doing something similar to what MyST is doing, in what it has borrowed from reStructuredText and Sphinx, by providing a standard entry point for custom "directives" (or something along these lines)?

I'm not sure if I'm cramming too much information and questions into this that cross over into other RFCs, future RFCs, existing feature requests, etc. but I feel like the overlap at times may be related to what ways Dendron may decide with syntax and what plugins can do with what happens inside of notes (such as if someone added support for another diagram other than Mermaid that could be rendered in preview and in generated sites).

This RFC looks more like the standard format in which a plugin is created, distributed, etc. in a way that will allow them to access separate, extensible entry points for pods, note lifecycle hooks, and note traits. Which would mean also future entry points. If that's the case, I'm not sure how much of my discussion post relates directly to the RFC, or if it is just food for thought. 😅

[SeriousBug]

Something else bought up is allowing plugins to add markdown extensions (for example, a Dendron plugin that would add admonitions syntax).

This could be done by plugins providing a parser/compiler plugin.