Manually start markdown rendering

The markdown renderer starts rendering every time there's a change in the note body, but can I force it to render manually at any given moment using the current plugins API?

I thought of a "dirty" trick to accomplish this, which is to trigger the editor to insert some dummy text (ideally an empty string), then the renderer will be able to pick up those changes and re-render. But I don't know the downsides of this sneaky approach.

What should I do?

The view is a rendering of the Markdown text. If the Markdown text changes, the view is updated. But if you need the update the view even though the Markdown hasn't changed, then there's a problem in your implementation.

What do you want to do?

When the user changes the path of the CSL file from the settings, the style of the rendered citation stays as it is until there's a change in the markdown text.

So, the behavior I need to implement is that when the CSL file path changes, I want to re-render the note body.

Hmm, yes it's a bit like custom CSS then because it's altering the rendering even though the Markdown stays the same. The only way in this case is to restart the app.

But ideally there should be some kind of tag in the Markdown content that tells what citation file to use. Then whenever that tag is changed, the Markdown is changed, and the view update. That's the proper way in general because that way the Markdown text is self-contained - it has all the information needed to be rendered to HTML.

Can you think of any way to implement it that way?

1 Like

I don't see how that can be done. AFAIK, the API is designed such that it is possible to send messages from the content script to the plugin and get responses, not vice versa.

Maybe I can do some polling in the content script to get the citation style from the plugin? But this has performance drawbacks.

The API allows the rendered content to dispatch messages to allow basic interactions like checkboxes. But sending messages to the view is not supported and is an anti-pattern because it would mean that the view is not a rendering of the content anymore but an SPA.

All I can suggest is to ask to restart the app when the user changes the citation file in the settings.

2 Likes

This sounds good.

Hmmmm, sorry for not making myself more clear from the start, but the style of the rendered bibliography does not always stay the same. For example, if I changed the path of the CSL file and waited enough time, then returned back to the note, the style of the rendered bibliography changes according to the CSL file.

However, if I changed the path of the CSL file and went back immediately to the note, changes might not be applied.

So, overall it is a very weird situation, so to speak. In your opinion, is showing a message box telling the user to restart the app still the best idea?

What I mean is that what's rendered should be driven by the markdown text only, not by external dynamic parameters.

Right now you want to change the csl file path on the settings and you want the view to change as a result, and that can't happen because the markdown hasn't changed.

So how to solve this? One solution is to put the CSL filename inside the markdown document, in a tag, as I've tried to explain above. So for example the user would add this tag at the end of the document:

  • [citations] - that would render the citations using some default CSL.

  • [citations:PATH_TO_CSL] - that would render using the provided csl file path. If the user changes the path, the document will naturally re-render without having to hack the renderer.

That's just an idea. And if that's not option, then restart is the only way.

1 Like

I guess I'll stick to restarting then :smiley:

It's not rocket science but yes, that's why I've been suggesting all along to stick with restarting.

But what about markdown options in settings (e.g. enable/disable katex)? They do affect the rendering, can't something like that work here?

Those are properties of the renderer - for example we have a table of content module, which can be switched on and off, but to add the table you'd add a [toc] tag because that's a property of the content. And it's similar here, the BibTex plugin can be on or off (renderer property), but if you want to add the citation list you'd add [citations] tag to the Markdown (content property).

You can get things working in a different way of course, but it means the drawbacks we discussed such as having to restart the app, or trying to trigger view updates even though nothing has changed in the document.

I was thinking more like with the katex plugin, if i have a math block that is rendered and then i go to settings and disable katex, then when i go back to the note the math block is no longer there.
I thought maybe something like this would be applicable here but I can certainly see how renderer settings may have a special treatment compared to everything else.

I guess these settings defines whether a particular renderer feature is enabled or not - whether you want to render Katex, or Mermaid, or not. Then how the associated Markdown is rendered is normally defined in the document itself - obviously the Katex code is going to be in the Markdown text, but I think the TOC tag also supports parameters and probably others.

This is generally a good thing because it makes the document more self-contained - you can export the note, import it back later on, and you don't have to remember what settings were used to render it last time because it's all in the Markdown text.

That's why if something is going to change how a document is rendered, then it should (ideally) be part of the document itself.

So, Is there a way using the API to show the "The application must be restarted for these changes to take effect. Restart now" Dialog?