Combining plugins

Why are you against combining plugins?
When people check features against needs and include plugins its easy to assume they will work together, but they often don't. This could be made as easierby some sort of app message bus. A plugin global variables registry or better, a subscribable event bus which is well developed in JS. Being dependancies means upgrading the plugin manager but a plugin collection plugin could do that. I am using 3/4 of the plugins already to see which work together and I am sure I will stick with 2/3 at least. When plugins work together users design their own workflow. Sure its generates scripting cruft but it increases contributors.
Besides script monkey I also like 'tree style tabs' in my browser because it has a few useful plugins built on it. It saves programmers maintaining a big plugin even if they do need to stay on top of changes. More important is that the plugin programmer exposes their own hooks/api and changes it as rarely as possible.
I noticed that the rich text editor is deleting html comments, and that math mode plugin keeps its formula definitions there, including hide:expression/result. Wouldn't it be better to fix bugs like that, to allow plugin glue code to live in the markup body instead of be hidden and display in panels. Markdown exposes its coding, not its parsing, why shouldn't plugins? That way plugin features could more easily adapt to SSG exports without finding out too late that. what you saw on the screen can't be shared

1 Like

Because they become larger and more complex. And I might have to deal with functonality I do not need and in the worst case which I can't turn off.


I agree. For that reason I would like mermaid made into a plugin as I prefer plantUML. No need for both. But what do we do until we get our favorite combination of features without any cruft? If we have a method for plugins to declare safe variables publicly to other plugins then we can either join them or not. Currently plugins are largely independent. The safe common variables are the API. That is important for quality control of plugins.
But each plugin already needs quality control. Repeating todos is freezing my computer. Most plugins are based on professionally maintained libraries. I am just saying it would be good to have some outside the API event bus that can be subscribed to. Feature bloat is something I rarely notice in browser plugins. Developers seem happy to separate the standalone parts and plugin interconnectors usually need to be manually linked

You can always tun off mermaid in Config -> Markdown. Btw, there's a PlantUML plugin.

Silly me. Forgot the options > markdown > enable mermaid. Bad example. A better example is the PDF renderer which needs a plugin to remove it

I am not a coder, just a systems integrator but..
Electron ipcMain is an Event Emitter channel to a renderer process (web page) and is also used for messages sent from a renderer to the main process. To get the frameId of a given renderer context (editor or preview or plugin panel) use the webFrame.routingId value. E.g.
console.log('My frameId is:', require('electron').webFrame.routingId)

For plugins to fully interact via the API, ipc-main would need a list of plugin event listeners that plugins can add and subscribe to.

But this does not leave the markdown as the single source of truth until the channel is the markdown editor frame. At that point it can be exported to SSG and renderers on other platforms like vs code, discourse and mobile apps where they have the plugin support. The markdown syntax should be as small and readable as possible. Putting that syntax in html comments like the excellent math plugin is great because it will rarely render when the plugin is absent but it can clash with some editors like Joplins WYSIWYG which removes it permanently from the markdown. Ideally syntax should be made visible by a control click in the preview pane (eg rich markdown viewer).

Html markdown comments like... <!-- this --> work in Joplin but are still not common to all extension libraries, requiring an translation step. In swift markdown they /** start and end */. Better to fix the WYSIWYG bug really. <!-- html comments are tiny and even work in discourse -->
Inline review comments would presumably be the only comments without an extra plugin label. The label helps md readability anyway. eg. <!-- plant: cOnTent --> being parsed to <script src="scripts/plantUML.js"> cOnTent </script> vs <-- my unlabeled opinions -->

I notice that the new templates plugin may have a way to work with other plugins. I haven't upgraded yet to try it. It should be possible to use it to make mermaid templates for example. The template is passed to handlebars which creates markdown in a child process. I am looking into the codemirror events registry to see how to expose parts of it to the API. Do you know where I can find a Joplin component stack diagram? There is a lot of history here with a steep learning curve

1 Like

So which plugins do you want to combine and why? Whats your best use case?

Who are you asking? You can't be asking me, because I said I am against combining plugins.

Seems there are not many responses from other people so I'll try to start the discourse.

First, thanks for registering on the forum. Welcome! I think a lot of knowledge is contained here about the app, so looking around is always a good idea.

Second, I understand English might be not the native language for you and I appreciate the effort to make your thoughts known. Yet currently I can't understand a few things with your posts.

I get that you want to combine the plugins and there's some rational behind that but can I ask you please clarify the reasons to do it in one easy to follow list?

Right now, motivation, suggestions and just random comments are in the same blob of text and it's kinda hard to get what's your end game.

Can you illustrate common use cases and advantages over current modular approach?

Do you have implementation in mind?

Would you like to work on it by yourself or is it just an idea for devs to consider?

P.S. just a user here, trying to give a hand another one. Please don't expect much from me.

One reason is that each plugin comes with a memory overhead, even if does nothing most of the time, like the backup plugin. It may not be significant if you have only a few plugins but as more functions are being added it will become an issue especially for less powerful devices.

1 Like

Yeah, modular standalone plugins are the status quo/consensus here at the moment and there's solid rational behind it. Thanks for listing the key points. Moreover, I'm not trying to question that or support the alternative, rather just structure the thoughts of the topic starter in easy to follow way.

What I get from this thread so far (I'll let the topic starter correct me if I don't get something):

Out of frustration with some bugs/features, topic starter jumped the gun proposing changes to the core without actually getting answers to his questions.

As I understand it has to do with his communication style: he'd like to learn how things work under the hood and somehow "help" with development. So he just documents his personal progress here using motivational, a bit twitter-like tone. This can suffice for social media but here people expect more intentional directed approach toward some sort of goal (even if it's just contribution to a discussion). In the end, there's no complete response for almost two weeks (I hope tessus won't take it wrong way).

As there's no mentor to guide him, he dwells on not the most productive direction. So, I suppose, it would be beneficial for the guy to just ask for guidance directly rather than post rhetorical comments on app's design. And yeah, I understand that communication is hard and he might not succeed at "receiving" the guidance in the end.

So there's that.

Nope, I don't. I just don't know what to answer, because I don't understand what he/she wants.

Actually Tessus created this thread not me as the reply I wrote to him was too long. So I felt obligated to elaborate and went down the rabbit hole of the programs structure. I realised that I was just adding notes so I stopped to collect them to form a direction.
You could call offering a software diagram/stack mentoring I guess, just so I can use the right words. I will get back to it once I fully resolve all the issues I am having with the plugins at the moment. As usual with these things there are many points of entry to fix a problem so its best to focus on those that remain after trying everything else and checking all the forums. Its a lot to read just to get up to speed but I will do a basic write up for those wanting to enter development of Joplin. That's where mentoring/editing would be useful. Besides, I will have a flood of replicable issues at that time.
P.S. Plugin combinations would require a sets of plugins system

Okay, thank you for explaining the origins of the thread.

So, let's go one topic at a time. Can you confirm/correct and respond to the next points?

  1. You're facing a plugin related problem.
    can you document in detail what the problem is that? Is it about repeating to-dos?
  1. You also have an idea to extend template plugin for mermaid diagrams and you want to try to do it yourself apparently.

Here, I would strongly suggest to discuss your idea before spending your time on more technical level

  1. For that purpose you want to learn about Joplin's design therefore seeking some resources (you call it "a component stack diagram") to start as well as help to clarify your understanding.
    For now, you're trying to do your part and study the forum to resolve arising questions yourself.
  1. Meanwhile you're learning about the design, you'd like to improve development documentation.

In my perspective, each of those points is a separate topic hence it would be best to create it's own thread for them. Mushing them all together (and labeling them as "Combining plugins") makes it hard to read and respond appropriately. However, as I am just a user, I'd like to get an opinion of devs here.

Coming back to the main topic of this thread, as it got a bit messy at this point, I'd like summarize what was said before in this thread.

  • CalebJohn was interested in a system of default plugins
  • Tessus provided technical suggestion to have a configuration file to download and install lists of plugins at startup
  • Laurent confirmed that Joplin is going to have a few default plugins

Just to clarify: at no point there was a discussion of combining .jpl plugins together in one master plugin.

  • The topic starter suggested heavier integration of plugins between each other once they are already installed.

So, as it wasn't discussed before I expect topic starter to elaborate on the suggestion.

@kimcosmos, can you please go over this post and respond to the questions listed there?

Heavier integration of plugins would require checking that all listed plugins needed for certain actions were installed. Like a dependency system. Lists of plugins that work together and can be installed together

Yeah, that's right. So, in your opinion, having dependencies (and problems associating with it) justifies heavier integration?

if so, how? in other words, can you illustrate common use cases and advantages over current modular approach?

Piggybacking on the previous question, do you have implementation in mind?

You are asking me to repeat myself but more concisely. The simple answer is that I am not ready to answer your questions right now. I have over 20 documented plugin problems now so I need to see which are relevant to plugin combinations. However any example I give probably should have its own thread. I could give you 1 example purely to illustrate how different parts of the application fail to work together. I have avoided doing so because of all the reasons you already mentioned.
You want

  1. The advantages over the current modular approach
  2. Illustrated by common use cases

My objection may simply be about plugin writers using webview/iframe panels instead of making permanent changes to the actual markdown. Thus providing features that cannot be combined with information in other panels.
Maybe needed API variables can be changed for documents not currently in the console. I don't know. I am looking.
So. Please be patient.
Here is an example that includes the spoiler plugin and the outline plugin with userstyle.css and the pdf preview. Does the preview need upgrading? Will it export? Does spoiler have unannounced userstyle values? This is not the thread to discuss it