Plugin API: How to modify the way markdown is render

Questions & Help
1

Is it possible to use the API to make a simple plugin that, for example, replaces :hw: in every block with Hello World! at render time (i.e., keeping the original file with the :hw:), without using any slash command? Just installing the plugin and every instance of :hw: visible is rendered as that other string. Of course, the rest of the text should keep standard markdown render.

I tried to use onBlockRendererSlotted, but I don’t understand the docs and I haven’t found any examples on rendering the Markdown. I then tried using provideUI inside, but it receives HTML. Can I use Markdown instead?

2

Bump!

Is there any way I can accomplish that? Basically, given a certain block I want to:

  1. In the markdown content, replace all instances of :hw: with <span style="color: pink">Hello World!</span> (said and done)
Block Example

Original: A block with **Bold** and *italics* and :hw:
Modified string: A block with **Bold** and *italics* and <span style="color: pink">Hello World!</span>

  1. Render this new markdown string
Block Example

Original: A block with **Bold** and *italics* and :hw:
Modified string: A block with **Bold** and *italics* and <span style="color: pink">Hello World!</span>
Rendered string: A block with <b>Bold</b> and <i>italics</i> and <span style="color: pink">Hello World!</span>

3

I guess it would also be fine if I received the HTML of the original markdown, and then I replaced the non-processed :hw: to insert the span.

4
5

The other is a feature request, this is a question that might be solved with that feature, or might be solved with another workflow

Isn’t MutationObserver a bit hacky as it doesn’t use the logseq API? What should I observe? Every span.inline? The whole body? When should I start the observer?

These are questions whose answers could change every version, and that require some reverse engineering.

6

In my opinion:

  • Text expanding is a hack in itself.
    • The non-hacky approach is to use a macro.
  • As long as there is no strict standard (if any at all), every postprocessing approach:
    • implies some reverse engineering
    • risks breaking in the future
      • Open source facilitates easier healing.
  • Logseq’s API covers relatively few things
    • waiting for its enrichment may take months

Given the above, I consider the MutationObserver approach as realistic:

  • observe element app-container
  • start the observer since the beginning
  • use a live collection, e.g. getElementsByClassName(".block-content")
    • Can easily select span.inline (or anything) from there.
  • mark each processed element
    • That’s both necessary and more than enough to avoid all delays.
7

Oh, seems to work, thank you very much!

By the way, when I install the plugin from GitHub release, it raises an error: DOMException: Blocked a frame with origin "lsp://logseq.io" from accessing a cross-origin frame

It seems I have to modify the manifest in the marketplace and then its done!