The latest version includes a rewritten rendering engine. The goal was to simplify the rendering logic, to stick more closely to markdown-it implementation, and to move extra logic in plugins. Doing so fixed various small bugs and will make it easier to make further changes.
As far as I can see it works as previously but if you can give it a try that would be great. The desktop version can be downloaded from there:
Hi @laurent Does this mean that you’re looking into supporting user defined (markdown-it) plugins? With this new renderer it should be much easier to support user enabling/disabling of certain features and it should also be possible to allow users to download/write their own markdown-it plugins.
If you’re not already working/planning to work on this I’d like to take a shot, as long as this is something you’d find useful.
At the moment, the plugins have to be added manually into the code directly and then it becomes part of the main app. But it’s not possible to take a plugin, drop it into some folder and have it load in Joplin, at least not at the moment.
Yes one of the goal, besides simplifying and cleaning up the architecture, was to enable support of the markdown-it plugins and to make it easier to enable or disable them.
All standard plugins should work out of the box but as mentioned to merlinuwe this is all at code level. i.e. to add a plugin, one would need to create a pull request that adds the necessary plugin to package.json, then add the line to enable it in MdToHtml.
If you’d like a plugin enabled or would like to create one, I guess the best would be to discuss it here. To decide if we add a plugin, we need to take into considerations a few things:
Ideally, the feature would be standard or almost standard Markdown (based on how widely used it is). For example, something that links “#” anchors to headers automatically would be good as it’s quite common. A counter example would be something that make all text wrapped in “&” to blink, because it would interfere with all notes that contain “&” and is not standard.
If we use a plugin, it needs to be reasonably well supported or else we need to fork it (like I’ve done for the Katex one).
That’s just some thoughts. In general I guess we need to look at each plugin on case by case basis.
Yeah, I miss this one as well. Even tried adding it once to the codebase a while ago, failed miserably. Ended up editing all my notes to use the <mark> tag. Hopefully enough people want this for it to make its way into Joplin soon.