With content script type ContentScriptType.MarkdownItPlugin, we can add plugins to affect the process of Markdown to Html. See example:
At the same time, we also need content script type of ContentScriptType.TurndownPlugin, so that we can write plugins to affect the process of Html to Markdown.
See is an example：
-
Web clipper clipping code blocks from Lua教程（一）：在C++中嵌入Lua脚本
-
Process to packages/lib/HtmlToMd.ts, code blocks's html is:
div with class of codebody representing code block.
-
Process to packages/turndown/src/utilities.js(isCodeBlock) , div with class of codebody is not matched as code block.
-
If we add a rule rules.codeBlockOfDivWithClassOfCodebody to packages/turndown/src/commonmark-rules.js
-
Web clipper clipping code blocks will ok:
If we can add content script type of ContentScriptType.TurndownPlugin, rules.codeBlockOfDivWithClassOfCodebody can add to an individual plugin, so do not need to change packages/turndown/src/commonmark-rules.js, so we do not need to add PR to Joplin, personalized needs are met without affecting Joplin's universality code.
Do you have a similar need? Do you support this need? Feel free to comment on whether you support it or not.
1 Like
Thanks for the description, although I'm not sure I follow the technical details. At a high level, what kind of plugin would benefit from this? What user-facing feature is not currently possible with the existing plugin API?
Another use-case I could see for this would be for optimizing the webclipper for specific websites. For example, a plugin might specialize in converting Discourse threads to Markdown. However, because websites can update how content is presented in HTML, such plugins may stop working quickly if unmaintained.
The plugin plugin-abc-sheet-music currently handles the rendering process from Markdown to HTML. If there are any modifications on the editor, the current status returned to Markdown as garbled code. If the plugin wants to save the modifications, it will need to affect the processing from HTML to Markdown, which is currently not possible with existing plugin API.
If the plugin wants to save the modifications, it will need to affect the processing from HTML to Markdown, which is currently not possible with existing plugin API.
Currently, one way to handle this is to add metadata to the generated HTML (see the plugin API documentation). This should also allow users to double-click to edit the generated HTML in the Rich Text editor.
(Edit: The documentation was updated with this very recently — I'm unsure how many plugins take the linked approach, if any).
If can affect the process of Html to Markdown, plugins can save user modifications, use's modified HTML marked with red ellipses can be parsed to Markdown, the modified HTML content can be directly saved to Markdown.
This plugin is equivalent to implementing an editor, where a plugin renders its own content (Md -> Html), after being modified by the user (directly in HTML format), the plugin itself can ultimately save the modifications (Html -> Md).
if user modify Html, plugin plugin-abc-sheet-music can directly save user HTML modifications to Markdown:
